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


Patrik Reali wrote

[in a very-hard-to-read message - please split up your posts into
paragraphs]

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.

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.

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.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/



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