-
Notifications
You must be signed in to change notification settings - Fork 16
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
Refactor type element #70
Refactor type element #70
Conversation
👋 Welcome back psandoz! A progress list of the required criteria for merging this PR into |
@PaulSandoz This change now passes all automated pre-integration checks. ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details. After integration, the commit message for the final commit will be:
You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed. At the time when this comment was updated there had been no new commits pushed to the ➡️ To integrate this PR with the above commit message to the |
Have you considered the name OpType? Since the code model API is mainly about "ops" and types are meta-data attached to such ops, the name seems a bit less general than "code type". |
Yeah. that would seem more consistent with what with did with |
(Code) Types are associated with results of operations and parameters of blocks. I did ponder |
On further reflection i will close this issue without integrating. It seems unnecessary churn right now. I will create another PR that focuses on the less disruptive refactor of |
Rename
TypeElement
toCodeType
, thereby avoiding confusion withjavax.lang.model.element.TypeElement
(CodeType
is closer tojavax.lang.model.type.TypeMirror
andjava.lang.reflect.Type
).Rename
TypeDefintion
toExternalizedCodeType
and enclose withinCodeType
.It's possible to go further and define a subtype
ExternalizableCodeType
that supports externalization toExternalizedCodeType
, copying the pattern for operations. This requires some adjustments to the externalization of types that may be composed of other posssibly non-externalizable types e.g.FunctionType
. We can consider this separately to this PR.Progress
Reviewers
Reviewing
Using
git
Checkout this PR locally:
$ git fetch https://git.openjdk.org/babylon.git pull/70/head:pull/70
$ git checkout pull/70
Update a local copy of the PR:
$ git checkout pull/70
$ git pull https://git.openjdk.org/babylon.git pull/70/head
Using Skara CLI tools
Checkout this PR locally:
$ git pr checkout 70
View PR using the GUI difftool:
$ git pr show -t 70
Using diff file
Download this PR as a diff file:
https://git.openjdk.org/babylon/pull/70.diff
Webrev
Link to Webrev Comment