Doug Lea wrote,
> I could not send varr to a method expecting an int, at
> least not without giving up volatile properties. So I'd need
> to reparameterize (and in some cases therefore duplicate, so
> could apply to both flavors) methods like:
> void reverse(int a);
> void reverse((volatile int) va);
> Plus rules for casts in both directions. And so on.
> The net effect on programmers is just not all that different
> than the special-classes proposal.
I agree that exploiting a language change wouldn't always be
simply a matter of sprinkling a few extra volatiles and finals
around. But I'm not convinced that it wouldn't quite often be
that simple. I'm sure that there's a large body of code out
there which wouldn't be hurt by volatility being lost for the
duration of a method call; and I can't see existing code being
hurt by a similar gain of volatiltity.
Hmm ... perhaps implicit conversions from (volatile int) to
int _are_ too dangerous, but from int to (volatile int)
should be fine so long as you don't want to insist on complete
protection from aliasing problems. But that means existing code
could be fixed, at least temporarily, without duplication.
> The net effect on the language is a new, fairly large set of
> rules that would take a while to iron out and would prbably
> meet a lot of resistence.
That's fair comment. But then, assuming that some progress is
being made on the genericity proposal, there are going to be
significant type-related language changes happening anyway.
Having said that, generics would make your proposal quite a bit
more palatable. I'd be quite keen to see some collaboration
between that JSR and a future memory model one.
-- Miles Sabin Cromwell Media Internet Systems Architect 5/6 Glenthorne Mews +44 (0)20 8817 4030 London, W6 0LJ, England email@example.com http://www.cromwellmedia.com/
------------------------------- JavaMemoryModel mailing list - http://www.cs.umd.edu/~pugh/java/memoryModel
This archive was generated by hypermail 2b29 : Thu Oct 13 2005 - 07:00:24 EDT