Function types versus arrays

[Reinier Zwitserloot]

On Mon, Feb 8, 2010 at 11:17 AM, Rémi Forax <forax at univ-mlv.fr> wrote:

> I'm also happy with List, perhaps we should introduce a new interface
> ReadOnlyList
> which is a super type of List and array of objects but that another story.
>
>

Nope. Can't be done. It would mean that List (and therefore, ArrayList) is
an 'instanceof' ReadOnlyList. Which sounds like a pretty bad plan.

The only way that's halfway feasible and does not result in instanceos of
"ReadOnlyList" not necessarily being readonly that I managed in thought
experiments is to create a new supertype of List which implies neither
read-onlyness nor mutability. This supertype then has 2 children, and as a
convention one should never implement this supertype directly, only one of
its two children (or subtypes thereof). One child is java.util.List (which
will more or less imply mutability), the other is java.util.ImmutableList.
The supertype, as it does not imply editability, should not include the
write-only methods. Of course, java.util.Collection is also around, and has
both add() and clear(), so it too needs splitting up like this.

Naming it is very hard as almost all names have already been taken. The only
usable word left in my thesaurus is "Roll", which isn't exactly the most
logical choice.

Another option is to retire java.util. for collections and move them to
java.lang or create a new package for them. Then, java.util.List can be
deprecated, and the inheritance model can become:

java.lang.List (top-level, does not imply nor has the mutable methods, but
it doesn't imply immutability either).
java.lang.ImmutableList extends java.lang.List
java.util.List extends java.lang.List (deprecated - don't use)
java.lang.MutableList extends java.util.List (just wraps java.util.List. Use
this one when making mutable lists).

and ArrayList, Vector, etcetera are modified to implement MutableList
instead. On the surface this seems to be backwards compatible, but I haven't
delved very deep into the repercussions of introducing this, as now
(specifically: the java7 release) does not seem to be the right time. The
above does have the advantage of allowing one to define List classes that
implement java.util.List but not java.lang.MutableList as being ambiguous in
whether or not they are supposed to be mutable or not. That would fit the
notion of practical backwards compatibility: There are tons of
java.util.Lists out there today that are in fact immutable.


> > Cheers,
> > Neal
> >
>
> Rémi
>
>