Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

One thing with the current proposal that I haven't quite figured out is that it seems to me that the decision of whether a certain type is an "object" or a "value" is pushed to the use site rather than definition site, so the same type can be used as both object and value at different sites — in a way that doesn't quite match the intuition for boxed types in, say, C++.


I believe this is because of compatibility concerns when types migrate from object to value or vice-versa. The linked doc[0] says "operations can differ between value and reference types [...] This means that, if we are to support migration, we need a way for legacy classfiles to make a local decision to treat a given type as a reference type".

It is agreed in general that whether something is a value type is a definition-side attribute. However if code was compiled expecting the Optional value (e.g. does an ==) but it is now an Optional object, what happens? The identity check is different than the value-equals one. The doc goes into more detail on some differing things here.

I haven't studied the arguments or read the doc fully, but I'd say if you make it where it can only migrate one direction, object types to value types, you can solve the two big issues of equality (equals() is intercepted by the JVM for value types to imply ==) and nullability (value is never null, == null becomes always false). There may be other issues with hashCode, use as mutex in synchronized block, etc.

Maybe another approach is to have the value type implement "ObjectLike" if it wants to exist in the L-world. There needs to be a separation between what an "object type" is and what an "object type" can do. The latter causes migration concerns, the former is just about state and copying/reference semantics.

0 - http://cr.openjdk.java.net/~jrose/values/value-type-hygiene....


Are they going for the C# model of automatic boxing of value types?


Doesn't C++ behave in the same way?

Sure, classes are generally designed for either being used as value types or OO Objects, you can prevent objects from being copyied/moved and if you really go out of the way even from being created outside of the heap, but in general the value vs reference semantic is left at point of use in C++.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: