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
While having recursive structures is troublesome because it complicates the interpreter's implementation (copy by value on an infinitely recursive structure is... complicated), having fields with pointers to yet undefined types should not be an issue.
I'll consider it for the second version of Fate.
The text was updated successfully, but these errors were encountered:
The parser_rework branch added the FutureType class to Fate (to delay having to distinguish between a string and a variable name until it becomes clear whether a string would make sense). This might make it easier to add the feature:
Creates the YetUndeclaredType class, which extends FutureType.
Constructor takes a string, which is the name of the type that is expected to be declared in the future.
YetUndeclaredType keeps track of all created instances in a Map<String, Collection<YetUndeclaredType>>.
Upon any type declaration, call some static function in YetUndeclaredType to see if this resolves any of them.
In Fate, the user can simply use (future_type not_yet_declared_class).
The user might have used this to refer to a type that was already declared. This should trigger a warning, but still work.
The user might make infinitely recursive types. The feature should be implemented without checks for this in its first iteration (with a warning on Fate documentation not to do recursive types).
While having recursive structures is troublesome because it complicates the interpreter's implementation (copy by value on an infinitely recursive structure is... complicated), having fields with pointers to yet undefined types should not be an issue.
I'll consider it for the second version of Fate.
The text was updated successfully, but these errors were encountered: