On Feb 11, 10:00 pm, Owen Jacobson<angrybald...@gmail.com> wrote:
On 2011-02-11 21:44:14 -0500, Eric Sosman said:
On 2/11/2011 9:20 PM, Tom McGlynn wrote:
...
Add a new optional element in the definition of an interface which
defines a class that does the default implementation of the
interface.
...
Are there other ways to do this? A factory method requires knowing
the class the factory resides in and I can't really think of other
patterns that address this. E.g., one could add
newSet(), newList() and newMap() methods to Collections but that's not
especially elegant to my eye since there's no special language
relation between the List interface and the Collections class.
I think that's the crux: There's no special relationship between
an interface and its many implementations; the relationship is one-way.
Adding the other-way relation -- the ability of an interface to name a
class and say "This is My beloved Son, in Whom I am well pleased" --
doesn't seem to me to add much utility.
This proposal also "bakes in" a circular dependency between an
interface (List<T>) and its default implementation (ArrayList<T>), such
that there is no way to compile or load either class without the other.
While such circularity is sometimes hard to avoid (enums with
per-constant bodies, for example, are inherently circular), they're not
recommended style and they can lead to hard-to-debug classloading
problems if you're not careful.
I can't think of a use case for this outside of the collection types,
either, and there are already idioms for those. This feels like a
sublimated complaint about the standard library's choice of naming
conventions (List& ArrayList, rather than IList and List as with .Net
or informal protocols and list() like Python).
Interesting proposal, but I think it contains unfixable flaws.
-o
While I hadn't thought of the circular dependency issue, I think that
the existence of such would depend upon the details of
implementation. If the interface included a direct reference to the
default class I think you'd be right. However suppose the interface
only has a reference to a string containing the name of the default
class. Then you can load and use the interface without loading the
default class. The compiler would know to use the class name for the
default class when the default was invoked in a constructor.
Other use cases:
This approach comes into play when interfaces are used to describe a
root type of a set of objects with different implementations, where
the root type describes the object as a whole. In many cases (perhaps
most) interfaces are used to describe only one aspect of a more
complex object (this object can move, or this object needs to be
validated, ...). You would not want to use defaults in this second
case, since you can't allocate only one aspect of an object.
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();
Just because you like 'ArrayList' doesn't mean that I do. The benefit (not
microscopic. Bad idea.
Ceci n'est pas une fen??tre.
..___________.