Skip to content
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

Consider looking at Java's parallel effort #86

Closed
bakkot opened this issue Nov 11, 2019 · 2 comments
Closed

Consider looking at Java's parallel effort #86

bakkot opened this issue Nov 11, 2019 · 2 comments

Comments

@bakkot
Copy link

@bakkot bakkot commented Nov 11, 2019

There has been an ongoing effort to introduce value types to Java since at least 2012. Obviously they have very different constraints, but I expect it's worth reading about their effort anyway.

I believe the current proposal is here, and some links to history here, although note that these focus more on implementation than on how it would actually be used by programmers. There's a bunch of other docs spread out in random places too, like this one from 2014 which covers a lot of details as they were at the time.

This isn't really an actionable issue; I just wanted to point it out as a potential source of inspiration (at least for questions to ask about the design). Feel free to close this once you've read it.

@rickbutton

This comment has been minimized.

Copy link
Member

@rickbutton rickbutton commented Nov 11, 2019

This is a fantastic idea. I'll make sure to read it and digest/summarize any thoughts/strategies that might be useful for us here.

@rickbutton

This comment has been minimized.

Copy link
Member

@rickbutton rickbutton commented Nov 15, 2019

I've read through the links you've posted, and done a little digging on the side on this. The biggest takeaway from the State of The Values white paper (that is relevant to us here) is likely that it prefers element wise comparison and they don't have identity.

The current JEP 169 is effectively a deep freeze, where after the deep freeze it is invalid to observe the identity of the object, or attempt to mutate it. This is interesting because this is analogous to JS's current method for immutability (minus observing identity), which requires creating a mutable thing and then transitioning it to an immutable state. This JEP seems to be mostly performance oriented, which likely won't apply here since the performance benefits this JEP suggests via the lockPermanently operator don't materialize in JS via Object.freeze.

Thank you for pointing these docs out! I'll close the issue with this comment.

@rickbutton rickbutton closed this Nov 15, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.