Typemaker 1.1 rebased - fixes and improvements #2208
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
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. |
out-of-phaze
force-pushed
the
experiment/typemaker-1.1-rebase
branch
from
e14baf9 to
004b1d9
Compare
out-of-phaze
force-pushed
the
experiment/typemaker-1.1-rebase
branch
from
004b1d9 to
1918f37
Compare
|
This pull request has conflicts, please resolve those before we can evaluate the pull request. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.