This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: values types for Java
- From: Per Bothner <per at bothner dot com>
- To: Patrik Reali <reali at acm dot org>
- Cc: java at gcc dot gnu dot org
- Date: Sun, 19 Oct 2003 09:35:13 -0700
- Subject: Re: values types for Java
- References: <001301c3963f$21ff9590$0301a8c0@pcprr>
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/