values types for Java
Sun Oct 19 19:12:00 GMT 2003
From: "Per Bothner"
> Patrik Reali wrote
> [in a very-hard-to-read message - please split up your posts into
I'm terribly sorry, this never happened before! I'm going to check what is
> > Hi,I completely agree with you on the need for structs in Java,having
> > programmer specifying them allows to have theirbenefits without having
> > pay for expensive compiler optimizations.I will gently disagree with
> > 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
> > important point.
> One of the important "use-cases" of a struct is being able to
> return multiple values as a unit without heap-allocation. I.e.
> we want to heap allocated the result struct - but it obviously
> must be able to "escape" so we need to be able to copy it.
> The goal of my proposal *is* to be able to stack-allocate
> structs. The real question is what happens when we pass a
> struct to as a parameter to a method: would it be (conceptually)
> copied or passed-by reference. In my proposal, that's an
> implementation detail, since struct are immutable value types.
> Since we do need to be able to copy methods results, then it
> is more consistent that the parameters are also copied. In
> practice an implementation might copy small structs and pass
> larger structs by reference, for example.
OK. This is obviously something my solution cannot do. The only workaround
my proposal can offer, is to pass one stack-allocated value as parameter and
let the callee set its values, the pass-by-reference semantic will do the
> Being able to pass stack-allocated object by reference, and
> have the called method be able to modify the object is another
> use-case. However, it's a different use-case, and it the
> same solution may not be the right one for both problems.
> This message http://gcc.gnu.org/ml/java/2003-10/msg00134.html
> suggest one solution, but it isn't as well thought through as
> the value types proposal. What we'd like is a coherent design
> that solves both use-cases.
I think that the most difficult part of the design is the compatibility with
Java, such that compilers that do not support value-types will be able to
generate correct code.
You have many use-cases in mind: could you please list them all?
> Of course this is all academic, unless someone is inspired to
> implement these features and/or submit it as a JSR. Just to
> make sure there is no misunderstanding: This is just a paper
> design. I hope if/when someone implements this feature they
> do it right, but I would only work on the implementation if
> I were paid, which seems unlikely.
Same for me.
A JSR may have the advantage that being a new standard, it can propose
changes that are not required to be compatible with the legacy compilers.
More information about the Java