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
Currently the type(...) Statement is a complete hack and it simply prints out a string representation of the Claro type of an expression. Instead, it should actually be an Expression instead of a Statement and it should return a meta value which is of type Type. This would allow higher order programming allowing type "reflection".
This is currently done entirely at compile-time and I don't think that's what a user wants when they call type(...), they want runtime information. We need to make sure that all Claro builtins support the getClaroType() method, and at runtime we should be deferring to that method to determine the type.
We'll come up with some standardized way to reference non-Claro types later after native Java interop is supported. For now we should hunt down and kill all non-Claro-native types and replace them with a Claro equivalent in order to make runtime type checking a supported feature across all types at least until Java interop happens in some magical future.
The text was updated successfully, but these errors were encountered:
Currently the
type(...)
Statement is a complete hack and it simply prints out a string representation of the Claro type of an expression. Instead, it should actually be an Expression instead of a Statement and it should return a meta value which is of typeType
. This would allow higher order programming allowing type "reflection".This is currently done entirely at compile-time and I don't think that's what a user wants when they call
type(...)
, they want runtime information. We need to make sure that all Claro builtins support thegetClaroType()
method, and at runtime we should be deferring to that method to determine the type.We'll come up with some standardized way to reference non-Claro types later after native Java interop is supported. For now we should hunt down and kill all non-Claro-native types and replace them with a Claro equivalent in order to make runtime type checking a supported feature across all types at least until Java interop happens in some magical future.
The text was updated successfully, but these errors were encountered: