-
Notifications
You must be signed in to change notification settings - Fork 125
Typemaker 1.1 rebased - fixes and improvements #2208
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
Typemaker 1.1 rebased - fixes and improvements #2208
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
InspectCode found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
e14baf9 to
004b1d9
Compare
004b1d9 to
1918f37
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
|
Closing in favor of #2313 |
A bunch of fixes/improvements to typemaker inference, plus:
DMValueType.Instanceis now the default when doingas /some/typepath.as path(/some/typepath)can be used to specifically denote 'a typepath of type/some/typepath'.as /list(some union astypes here)for normal lists,as /list(some union astypes here, some others here)for associative lists. Empty lists currently always match all typed lists because type info is not tracked at runtime. Similarly, a list with only keys and no associated values can match a typed associative list (this was necessary to fix some stuff on TG, and besides, it's hard to differentiate betweenlist("foo")andlist("foo" = null).as params[1]astypes syntax has been added. You can also even doas params[1] as instanceto denote that, ifparams[1]is a path, this value is an instance with the same type. (This is useful for singleton getters.)I beg you, please help me find some other way to do the params stuff other than just threading
procParametersthrough the entire parser. It's SO BAD. I hate it. Can it go on like expressionContext or something????Rebasing this was a pain and stuff might be totally broken, but I'm gonna throw it at some codebases to make sure it doesn't totally explode.