Closed dgp1130 closed 7 years ago
Added static typing. Uniform now requires a declaration before an identifier can be used. Declarations must be put in the root scope and use the grammar <type> : <identifier> ;
The full grammar on the wiki has been updated to reflect this. This addresses the issue of using submitting the text on
into one of the text fields on car form. I didn't bother with checking types at compile type as that will be handled by #49.
I removed the is
operator as part of this. It was intended to check types dynamically, ie. @isString: make is string
. Since types are statically defined in the Uniform file, this no longer makes sense, since make
was either defined as a string or it wasn't. Hopefully the programmer is competent enough to figure that out, since they're the one that declared it.
Also made some minor edits involving adding $(document).ready(function () { ... })
. I came across a few instances where Uniform was loading before the DOM and was unable to correctly initialize, so I added this to address that.
I like the new change. After working through the car form tutorial, I was able to pick it up fairly quickly. Is vs equals was already confusing so I'm glad the distinction is gone. You also mentioned adding integer, array, and date in this ticket. Do you want to add a separate ticket for those? Code review is done, but you can close this if new types are a separate ticket.
Dates / times are handled in #16. Created #63 for arrays. Created #64 for numeric types. Also created #65 and #66 for select boxes and radio buttons which are pretty significant input types.
Due to the issues encountered in #36, we will need to introduce explicit static typing. Every identifier would need to be declared with a particular type. Using an identifier without an associated declaration should result in an
UndeclaredError
. This would look like the following:In terms of types, we should probably have: boolean string number integer (should this be distinct from number?) date (eventually, but this doesn't exist yet anyways)
We will also probably want to eventually support array types (probably not right now):
We have two options for scope, either 1) require that they be declared in the root scope, or 2) allow scoping the same way we do with variables. The first would effectively make all identifiers global (eww, but sort of the way it actually works behind the scenes). The second would compartmentalize better, but is a little strange in that the user may have to declare the same variable twice in two different scopes, which can be a somewhat counter-intuitive.
I think I'm leaning towards making identifiers inherently global as I think the extra confusion and complexity of allowing scope would outweigh the small compartmentalization benefit it provides. Thoughts @sawyernovak?