Re: values types for Java

["Patrik Reali" <reali at acm dot org>]

Hi,I completely agree with you on the need for structs in Java,having the
programmer specifying them allows to have theirbenefits without having to
pay for expensive compiler optimizations.I will gently disagree with your
proposal. Structures usuallyare characterized by stack-allocation (or
embedding intoother data types) and cloning on copy-operations. You set
theaccent on the cloning, whereas I think that stack-allocationis the most
important point.As an obvious constraint, compilers and interpreters
withoutsupport for structs should be able to compile them as classesand
obtain exactly the same results.My (rather pragmatic) approach is as
follows: I want to marksome classes as potential structs (allowing the
compiler to allocate them on the stack or inline them into other types),and
I rule out all the operations on struct that would break the Javasemantic.
The compiler could then check that no semantic-breaking operation is taken;
this would also ensure thatcompilers without support for static allocation
would still generate working code.Rule 1: the programmer can mark a class as
"struct", thecompiler will optimize those classes for efficient
allocation.Marking can be done as you proposed using a special field.First,
the structs are not allowed to "escape", i.e. referencesto a struct should
be shorter-lived than the struct itself.Method calls are fine, but
assignements can cause a reference tobe set outside the current call-stack,
thus:Rule 2: structs cannot be assigned with "="This is an important step:
assignment can have two semantic:setting a reference or copy the whole
struct. Both areunacceptable: setting a reference allows the struct to
escape,whereas cloning is against the usual Java rules.Note that this rule
implicitly prevents from returning astruct from a function (the reference
cannot be assigned).Structs can still be passed as parameters, like classes
are, usingthe usual reference semantic.Exception to rule 2: it is allowed to
invoke a constructor(Point p = new Point(....)); but the static type and the
dynamic type must be the same.Rule 3: structs cannot be coerced to a
non-struct type (inparticular Object)This rule avoids using Object as a way
to circumvent the rule 2.There is no need to restrict inheritance nor
methods. Legacycompilers will implement struct as classes; newer
compilersare aware of them and can pass a vtable along with the struct
reference when they are passed as parameters.There is one problem raising
with "==" and "!=". I think theyshould be disallowed, because the correct
behaviour would be tocompare the contents (field by field), but this would
causelegacy compilers to generate more restrictive tests
(referencecomparison) compared to the newer compilers (field tests).Another
problem is that the compared structs may be of differenttype (unless struct
cannot be subclassed).There may be some limitations due to the garbage
collector (GC),in particular with structs embedded into a class. A GC must
bequite clever or conservative to decide that a pointer on thestack pointing
to the middle of an heap-object must keep theobject alive. (I guess this may
be more difficult in a type-awareGC than in a conservative one).I think this
proposal is simpler than yours, and at the same timecompatible to the Java
semantic. Your example with "Point" wouldfit into the above rules but for
the returning of a struct in a function; furthermore, Point wouldn't be
forced to be static nor its fields final.This proposal is still not
complete: the default values are notspecified, and I'm sure that more is
missing (I wanted to quicklypost an answer to your message).Many thanks for
raising the issue!Patrik-----------Patrik
Realihttp://www.reali.ch/~patrik/http://www.oberon.ethz.ch/jaos/