On 12/07/2009 11:49 AM, Jon Harrop wrote:
> Users will want custom comparison, equality, hashing and serialization for
> their structs.
This points out there are two (or three) inter-twined problem areas:
(1) The specification and properties of structs at the JVM level.
(2) The specification and properties of structs at the source level
(Java and other languages).
(3) Work in the JVM implementations are use structs efficiently.
Some design isues:
* Should the fields of a struct be 'final' - i.e. read-only?
Such "value structs" have a number of optimization advantages,
since it makes it easier for the VM to copy them around. And
most use-cases are fine with immutable value-structs - if you
need to modify a field, just assign a new value on top of the
old one. (This is cheap and optimzable since we don't need
allocation.) At least the HotSpot engineers have told me that
immutable structs are going to be easier to optimize and so
should be what we focus on first.
* How do structs interoperate with Object, if at all?
I.e. how do you box and unbox structs?
* Related to the above are issues of equality and identity.
Clearly a struct does not have "identity". Presumably the
== operator should be defined in terms of equals, which should
default to field-by-field equality. But now when the struct
is boxed, we suddenly get identity, and the meaning of
== changes.
We have the same problem with the existing primitive types,
where the meaning of == is "wrong" when they're boxed. A
fix is for valueOf to always intern; then == and equals are
always the same, and so does not break with boxing. (Of
course the interning can be conceptual and optimized away
for pure value types, as long as == is defined to be equals.)
--
--Per Bothner
[email protected] http://per.bothner.com/
--
You received this message because you are subscribed to the Google Groups "JVM
Languages" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/jvm-languages?hl=en.