Re: Default Interfaces: possible Java extension?
On 2/12/2011 9:34 AM, Tom McGlynn wrote:
[...]
In my own experience one of my long term projects involves combining
and manipulating images and my code has sets of classes for coordinate
systems, projections, samplers, classes that find objects. I would
have found it convenient to be able to say
Sampler samp = new Sampler();
to get a default sampler than to have
Sampler samp = SamplerFactory.createSampler(null);
which is more or less what I have to do now. The current approach is
a much tighter coupling of the invoking code to the sampler
implementation -- I need to know the interface, the factory class and
method, and how one gets the default. It would be nice to loosen it
up a bit. I probably wouldn't change my existing code much -- but I
would change the way I write new code.
Something still eludes me. You can do exactly what you've
shown, with today's Java as it stands -- if Sampler is a class.
It still seems to me that "interface with default implementation"
is not distinguishable from "class."
Are you looking for some kind of back-door multiple inheritance?
I don't see how "interface with default implementation" would be
of any help there: You could (and can) write
class Whitmans implements Sampler, Edible
.... but you'd still need to provide implementations for both. You
could not rely on the "default implementation" of Sampler to
implement Edible, nor vice versa.
However you are certainly correct that were this extension made, most
of the times that I'd use it would with collections. I don't think
that's a serious flaw -- collections are as basic to Java as arrays
and I use them in essentially any serious program.
Does this address the flaws you saw?
Responding more directly to Eric's comments...
I'm sure you're right that we'd bitterly complain about whatever
choices were made for defaults!
Why do I think it could be useful to bless a particular implementation
of the interface? My thought is that it's a good idea for code to
have minimal knowledge of the implementation of the objects they use.
Using defaults, the knowledge explicit in the invoking code is
reduced. The information burden moves from the invoker to the
framework designer and the temptation on the invoker to use special
features of a particular implementation is reduced.
I.e., if I want a list is it a good thing for me to have to explicitly
choose between ArrayList and TreeList and LinkedList? It's certainly
essential that I am able to make a choice if I need it, but I think it
would be better better if I can also say 'I don't care. Just give me
a list.'
And if the default List is some kind of highly-available multi-
machine synchronized-via-RMI-and-secured-with-crypto behemoth? "Ah,
but I know it isn't," you say -- but there you are again, cozying up
with the details of the implementation. (And backing away from "I
don't care," too.) To paraphrase the late Ken Olsen: When did you
last buy a default car?
Or, what if Java 1.9 changes the default implementation from
ArrayList to KoKoLittleList, and the latter turns out to be a poor
fit for your usage pattern? You were happy with the default not
because it was the default, but because it was ArrayList -- except
that now it isn't, and you're no longer happy.
I'll grant this much: It would be nice if Vectors and Hashtables
and StringBuffers in existing code magically transmuted to ArrayLists
and HashMaps and StringBuilders wherever possible. (In a sense, this
already happens with some StringBuffers.) But it seems to me that the
"wherever possible" is the Achilles' heel of the matter; the compiler
is ill-equipped to find such opportunities unaided.
--
Eric Sosman
esosman@ieee-dot-org.invalid