-
Notifications
You must be signed in to change notification settings - Fork 321
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
Let JavaScript parse JSON and write JSON ... #3987
Conversation
32c1ba3
to
0623886
Compare
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.
first batch of comments
Number -> JS_Object.from_pairs [["type", "Number"]] | ||
Integer -> JS_Object.from_pairs [["type", "Integer"]] | ||
Decimal -> JS_Object.from_pairs [["type", "Decimal"]] |
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 that these need to be accounted for. Does it work though? I'm not sure how it plays with self
tbh.
Regardless if it works (well if not - then even more so) - this really feels weird to look at - ofc not something to do for now, but I think we should figure out how to distinguish defining such methods for the instance and their static variants. My intuition would see them as rather separate definitions, instead of having to do such matches.
@hubertp @kustosz as you've been close to the statics - any thoughts? Is it even possible to have a static and non-static variant of a method with same name? I'm worried it may conflict with the Type.instance_method instance_ref args
call pattern, so I'm not sure if it is even possible. Still seems that from the 'user' (in this context: library developer) perspective, we need to be able to define some methods both on instances and on the type itself.
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.
Yes, these work. I agree that it is not a great pattern but is needed in the current set up.
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Json/Extensions.enso
Outdated
Show resolved
Hide resolved
b.append ["type", "Locale"] | ||
if self.language.is_nothing.not then b.append ["language", self.language] | ||
b.append ["constructor", "new"] |
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.
Why is the constructor
a method name? Seems surprising.
Do we even need the constructor
here? I guess it makes sense to be consistent with Atom serialization, but we put a method name instead of true constructor so we are not truly consistent anyway.
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 idea is to make it, so we had the information to deserialise.
Originally had fully qualified type names but decided against it for this version.
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Json/Extensions.enso
Outdated
Show resolved
Hide resolved
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Text/Encoding.enso
Outdated
Show resolved
Hide resolved
distribution/lib/Standard/Base/0.0.0-dev/src/Data/Time/Date.enso
Outdated
Show resolved
Hide resolved
_ -> value.to_json | ||
|
||
json.to_text | ||
"" + json |
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.
Why is ""
still needed?
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.
JavaScript strings cause an issue with the visualisation. The "" +
makes it an Enso Text and then it works,
distribution/lib/Standard/Visualization/0.0.0-dev/src/Helpers.enso
Outdated
Show resolved
Hide resolved
Working through broken parts of Visualization.
GeoJSON and Visualisation to go.
Co-authored-by: Radosław Waśko <radoslaw.wasko@enso.org>
Disable failing test for RuntimeVisualizationsTest.
Remove Vector.enso from parser comparison.
Remove Vector.enso from parser comparison.
More PR comments.
f6d0c11
to
75f3856
Compare
Pull Request Description
Use JavaScript to parse and serialise to JSON. Parses to native Enso object.
.to_json
now returns aText
of the JSON.parse
,stringify
andfrom_pairs
.JSON_Object
representing a JavaScript Object..to_js_object
allows for types to custom serialize. Returning aJS_Object
.type
andconstructor
property (or method to call for as needed to deserialise)..into
support for now.Data.read
to work.Data.fetch
API for easy Web download.Fixes defect where types with no constructor crashed on
to_json
(e.g.Matching_Mode.Last.to_json
.Adjusted default visualisation for Vector, so it doesn't serialise an array of arrays forever.
Likewise, JS_Object default visualisation is truncated to a small subset.
New convention:
.get
returnsNothing
if a key or index is not present. Takes another
argument allowing control of default..at
error if key or index is not present.Nothing
gains aget
method allowing for easy propagation.Important Notes
Checklist
Please include the following checklist in your PR:
Scala,
Java,
and
Rust
style guides.
./run ide build
and./run ide watch
.