A
Andreas Leitgeb
Arved Sandstrom said:Pretty much in the standard way, which would take advantage of the
marker interface in a way suggested by Bloch: you create an interface
that extends List and RandomAccess, and concrete classes implement that.
That's just not applicable to the Collections framework as it is:
We've all been taught to use interface-names for the static type
of variables to hold whatever concrete implementation:
ArrayList l = new ArrayList(); // discouraged
List l = new ArrayList(); // encouraged
As soon as I use a statically "List"-typed variable to hold my
ArrayList instance, I've irrevocably disposed of the *static*
information about RandomAccess'ness of the instance.
If we were to change the Collection framework to allow for static
dealing with RandomAccess'ness, then we would first need that new
interface RandomAccessList extends List,RandomAccess {}
and would then need all appropriate implementations to implement
that new interface. And also we would need to statically type
certain variables as RandomAccessList, if we really wanted the
compiler to be able to statically decide among a RandomAccess-
optimized code path or the default one (without locking in on
particular implementations).
That's of course just rambling. Marker-interfaces just aren't used that
way, but instead they are always checked at runtime. So, either Marker-
interfaces (such as RandomAccess) are an anti-pattern themselves, or
that pattern is one declared exception to the "instanceof"-red flag.