-
Notifications
You must be signed in to change notification settings - Fork 326
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
Reducing helper methods in Standard.Base.Meta
#12031
Conversation
engine/runtime-integration-tests/src/test/java/org/enso/interpreter/test/meta/MetaIsATest.java
Outdated
Show resolved
Hide resolved
engine/runtime/src/main/java/org/enso/interpreter/node/callable/InvokeMethodNode.java
Outdated
Show resolved
Hide resolved
engine/runtime-integration-tests/src/test/java/org/enso/interpreter/test/AnyOrStaticTest.java
Outdated
Show resolved
Hide resolved
final class MetaKindNode extends Node { | ||
final long execute(@AcceptsError Object value) { | ||
if (value instanceof Atom) { | ||
return 2; |
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.
I expect magic constant complains... but the most important thing is consistency with Enso source code and I am not aware of any other way to enforce it than having some tests (which do exist).
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.
Fair. It is indeed well-tested I think.
I'd just add a comment in both files mentioning that we want to be consistent with the other file - so if any modification has to happen it is easier to find where the relevant parts are.
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.
I don't want to risk loosing the green CI status.
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.
Is that really a good reason to submit code with bad formatting to the repo?
- All code follows the formatting guidelines
This is no longer true.
I know we don't (yet) have an official style guide for Enso but misaligned comments are surely not something we should introduce not-by-mistake.
There is a failure in test/Table_Tests related to removal of
Shall I create Update: 67fcec2 creates |
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.
Please provide instructions in a more visible location.
@@ -0,0 +1,48 @@ | |||
## Enso Signatures 1.0 | |||
## module Standard.Base.Meta |
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.
Snapshot of the Meta
API used by the Signature_Spec
fb3196f
to
4daed89
Compare
distribution/lib/Standard/Base/0.0.0-dev/src/Internal/Instrumentor.enso
Outdated
Show resolved
Hide resolved
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.
LGTM. Just minor nitpicks.
@@ -346,6 +354,30 @@ add_specs suite_builder = | |||
Meta.get_annotation My_Type .Value "bar" . should_equal Nothing | |||
Meta.get_annotation My_Type .Value "baz" . should_equal (My_Type.Value 1 2 3) | |||
|
|||
group_builder.specify "atom constructor with suspended evalution" <| |
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.
group_builder.specify "atom constructor with suspended evalution" <| | |
group_builder.specify "atom constructor with suspended evaluation" <| |
_ -> | ||
Test.fail "Expecting Meta.Constructor, but was: "+m.to_text | ||
|
||
group_builder.specify "atom without suspended evalution" <| |
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.
group_builder.specify "atom without suspended evalution" <| | |
group_builder.specify "atom without suspended evaluation" <| |
if (MethodRootNode.constructorFor(fn) instanceof AtomConstructor atom) { | ||
return atom; | ||
} | ||
if (fn.isThunk()) { |
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.
Can there be a nested thunk inside a thunk? If not, I would remove the for loop, and just check if fn.isThunk
at the beginning of the method and solve the thunk first.
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.
I am working on changing this line in a subsequent PR that is going to introduce Meta.Function
.
Pull Request Description
Meta.enso
in preparation of Function metadata call #5226Instrumenter
into internal packagesInstrumenter.uuid
(used by visualizations) intoRuntime.value_for_uuid
Meta.meta Cons...
behavior for no non-default argument constructorsImportant Notes
Meta.is_a
from a builtin into regular method had its issues - solved by Prefer module methods overAny
instance ones #12048Meta.Type
,Meta.Atom
, etc. constructors private revealed another set of problems - solved by Types withprivate
constructors can be public #12052Checklist
Please ensure that the following checklist has been satisfied before submitting the PR: