Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow empty typed things #60

Open
jarcane opened this issue Aug 6, 2019 · 1 comment
Open

Allow empty typed things #60

jarcane opened this issue Aug 6, 2019 · 1 comment

Comments

@jarcane
Copy link
Owner

jarcane commented Aug 6, 2019

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.

@jarcane
Copy link
Owner Author

jarcane commented Aug 9, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant