-
-
Notifications
You must be signed in to change notification settings - Fork 925
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
[Truffle] OM DSL #3172
[Truffle] OM DSL #3172
Conversation
I need to give the code a deeper review, but is there a mechanism to handle default values when a property is missing? E.g., we do this to avoid explicitly saving frozen or taint state for certain object types. Or is an override just the preferred approach? |
The frozen and taint fields aren't always in the layout so don't have a static location and therefore they need a node in order to specialise. We could look at generating those nodes as well - but we only have a couple of them. Other features I will add when I get to classes that need them: nullable and non-nullable properties, final properties, factory methods with default values maybe, configuration such as the int-to-long thing, inheritance, storing some fields in the shape, not the object, such as the Ruby class. |
Neat! |
Nice! |
* } | ||
* </pre> | ||
* | ||
* The properties are defined by getters and setter method pairs. They should |
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.
Minor issue, but I'd think "getters" should be plural here if used as a component of the pair description.
Looks great. I think the docs in |
I assume one often has multiple ArrayLayout-like interfaces in a package. Then I'd suggest to generate one file for the whole package named Layouts(?) with public static final ARRAY_LAYOUT and private class ArrayLayoutImpl. It would lower "conceptual surface" of the generated API by make impl classes invisible. |
Good idea, but I'm not sure it's possible to guarantee that your annotation processor will see all files in a single pass and so be able to do that. For example in incremental compilation in Eclipse, you won't see files which haven't changed. |
I expanded the stackoverflow answer a bit. It should be possible to get access to all elements in a package even in case of incremental compilation. |
Ah thanks for that - I'll take a look when I've got the next part of the DSL working. |
This is the next piece in the puzzle for the transition to pure
DynamicObject
and OM. Instead of specifying properties manually for all our existing core classes, this DSL generates them for you from an interface which makes it look a bit more like there's a real class there.@nirvdrum @pitr-ch @eregon @woess @thomaswue please review.
As you can't see the generated code in the PR, it converts this:
To this: