You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At present, all things have to be initialized with values at description or creation. This is partly due to how the internals work, and partly just a holdover from the earlier more dynamic, JS-like behavior.
However, when using things more as type-like objects or data schemas, especially with the new type notation, it can feel a bit ... redundant. Setting default values is often non-obvious or even makes no sense at all, and simply filling in nulls will create problems with typed things as they check their types on creation.
However, I believe some internal modification can be made to allow at least typed things to forgo the default values. The proposal then is thus:
Create a new syntax for declaring empty typed things without the initial value, ie: (describe Foo (bar (int?)) (baz (string?)))
Empty typed things are initialized with null values in fields, and the on-declaration type check is skipped
Checking types on copy is of course still enforced, so that new copies must provide all fields when copying or extending the original parent object
Possible concerns:
Default values can still have value in some cases like data schemas, as a form of extra documentation of the expected shape of the data
Creates more syntactic ambiguity on top of the existing thing declaration syntax
Has potentially thorny relationship with extend/inherit, as extending an empty thing would somehow also have to know if the original thing is empty or not, and there's questions as to how to behave when extending an empty thing with a non-empty or vice versa.
An alternate proposal:
Maybe we just need a damn type/struct/class keyword for such things, and to stop trying to thread the needle between JS-like dynamic objects, and more traditional type/struct declarations.
The text was updated successfully, but these errors were encountered:
A possible solution is to create a distinct undefined symbol that can be used internally as an exception to the type checker during instantiation, but which only passes the type check if all fields are undefined. Inheritance rules would also ensure that only a thing with undefined fields can extend another with undefined, to avoid ambiguous or incomplete objects.
At present, all things have to be initialized with values at description or creation. This is partly due to how the internals work, and partly just a holdover from the earlier more dynamic, JS-like behavior.
However, when using things more as type-like objects or data schemas, especially with the new type notation, it can feel a bit ... redundant. Setting default values is often non-obvious or even makes no sense at all, and simply filling in nulls will create problems with typed things as they check their types on creation.
However, I believe some internal modification can be made to allow at least typed things to forgo the default values. The proposal then is thus:
(describe Foo (bar (int?)) (baz (string?)))
Possible concerns:
extend/inherit
, as extending an empty thing would somehow also have to know if the original thing is empty or not, and there's questions as to how to behave when extending an empty thing with a non-empty or vice versa.An alternate proposal:
Maybe we just need a damn
type/struct/class
keyword for such things, and to stop trying to thread the needle between JS-like dynamic objects, and more traditional type/struct declarations.The text was updated successfully, but these errors were encountered: