Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25527 > unrolled thread

Re: Default Interfaces: possible Java extension?

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Default Interfaces: possible Java extension? Owen Jacobson <angrybaldguy@gmail.com> - 2011-02-11 22:00 -0500

#25527 — Re: Default Interfaces: possible Java extension?

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

[toc] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web