This is the mail archive of the java@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: values types for Java


From: "Per Bothner"
> Patrik Reali wrote
>
> [in a very-hard-to-read message - please split up your posts into
> paragraphs]

I'm terribly sorry, this never happened before! I'm going to check what is
wrong.

>
> > 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.
>
> 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
rest.

> 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.


-Patrik

--------
Patrik Reali
http://www.reali.ch/~patrik/
http://www.oberon.ethz.ch/jaos


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]