-
Notifications
You must be signed in to change notification settings - Fork 318
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
Split Atom suggestion entry to Type and Constructor #3835
Conversation
/** The type of an atom. */ | ||
returnType: string; |
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.
What is the returnType of the Type? I assume it will be always the type? I would left this field in Constructor, here it does not make much sense.
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.
Agree, it can be re-constructed from the module name and the type name. Removed
/** The atom name. */ | ||
name: string; | ||
|
||
/** The module name where the atom is defined. */ | ||
module: string; |
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.
- Docs still use
atom
term. - Isn't module entirely deducible from
returnType
field? Is there a possibility of "Extension constructors"?
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.
Good catch, I updated all atom
references in the doc.
The module
can probably be deducible from returnType
right now. But later when we start supporting more complex types, it might not be the case. I'd leave this field as is
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.
The parts on the engine side look fine from my perspective. I suggest to get a review from @kustosz - he can judge the best whether SuggestionBuilder
records the properties of the language properly.
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 nits
engine/language-server/src/test/scala/org/enso/languageserver/search/Suggestions.scala
Show resolved
Hide resolved
engine/runtime/src/main/scala/org/enso/compiler/context/SuggestionDiff.scala
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.
I have some reservations regarding Type
having a returnType
, and, in particular, the returnType
being the type itself. This is only true for no-constructor types, such as Nothing
. For types that have constructors, the type itself has a singleton type (containing the static methods). There isn't a notation for this singleton type AFAIK, but probably one should be made up. Otherwise we run the risk of IDE providing wrong suggestions. If a method expects a Maybe
, the word Maybe
is not an acceptable argument. So we shouldn't tell them that Maybe: Maybe
The |
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.
The Rust part LGTM.
Pull Request Description
Changelog:
Atom
suggestion toType
andConstructor
Important Notes
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide build
and./run ide watch
.