> I think there are pragmatic arguments which favour a language
> change. First, modifying array-using code to instead use
> VolatileXXXArrays is very intrusive. It's not just declarations
> which have to be changed, it's all uses as well. Worse, ...
I'm sympathetic. But all of the syntactic approaches I know of are
almost equally intrusive, and introduce additional language
complexities of the kind that C++ programmers know and hate.
For example, suppose the syntax is
(volatile int)[] varr = new (volatile int)[100];
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. 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.
> Second, there are a several places in the standard APIs where
> arrays are used as lightweight factories. And unless things
> have changed recently, this mechanism is recommended for use in
> GJ to work around the it's lack of support for type-
> parametrized object creation. If GJ forms the basis of the
> design for parameterized types in a future Java (which seems
> likely) there might be scope for conflicts.
I can't see any such conflicts offhand, but agree that
generics JSR folks ought to sanity-check this.
>
> Third, many working programmers simply will not believe that
> their compilers will be able to do a good enough job of
> inlining these methods calls. And if they're that worried about
> performance it's quite likely that they're the ones coding
> data-races: ie. the very consituency the VolatileXXXArray
> proposal is aimed at is likely to be the most resistant it.
>
Yup. This, and the need to revise core classes, are the two
best arguments against it. Still, I think they are outweighed
by other advantages.
-Doug
-------------------------------
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