One could call such "interfaces" "traits" instead with a new keyword or
such.
I don't really see /any/ benefit from this, though.
I'd have full blown no-holds-barred multiple inheritence, but it's too
late for that for Java. I have /no/ fear or loathing of diamond
inheritence -- as you say it is easy to require the join point of the
diamond to override to remove ambiguities.
Without fields or non-public methods, traits are crippled. Introducing
yet another different thing besides classes and interfaces just sounds
even more confusing to me.
From having innumerable cases where I wanted to mix in an interface
/with/ a default implementation, I'd love to just add default
implementation and non-public methods to interfaces.
Peter Becker wrote:
> I don't like the idea of allowing different access modifiers on
> interfaces, in fact I don't even like the fact that you can put a
> "public" in there.
>
> For me the different access levels actually define different
> interfaces already, i.e. a class implicitly defines up to three
> interfaces for different consumers (public, public+protected,
> public+protected+package-private) -- four if you count internal
> consumption. Java didn't invent a notion of an interface, it just made
> it explicit. Adding access modifiers into Java's interface structures
> would IMO deviate from the original idea and weaken the whole system.
> I would rather see something like "class X implements Y protected",
> although that wouldn't help for traits.
>
> For me a trait (I somehow prefer "mixin") is something quite different
> and much more like a class than an interface. Using interfaces for
> that purposes would IMO break the conceptual integrety of the Java
> type system even more; and the loss of abstraction that interfaces
> provide nowadays seems likely to cause pain later on -- e.g. the
> classic diamond pattern might get you (although I believe the diamond
> problem can be solved by enforcing overrides in the bottom class at
> compile time: everone who derives from two conflicting classes has to
> provide their own implementation -- brittle without versioned
> classes/interfaces, but at least it would break in obvious ways).
>
> Peter
>
>
> On Wed, Nov 5, 2008 at 2:42 PM, Jess Holle <[EMAIL PROTECTED]> wrote:
>
>> I concur. Traits would be a hugely useful addition.
>>
>> To make them really sing, however, one needs non-public interface methods.
>> For instance:
>>
>> public interface Foo
>> {
>> public void doIt()
>> {
>> // default implementation logic implemented in terms of getXInternal()
>> and/or setXInternal()
>> }
>>
>> protected X getXInternal();
>> protected void setXInternal(X x);
>> }
>>
>> Either that or one needs to allow interfaces to have fields, which is much
>> uglier. Having non-public accessors allows one to have virtual fields used
>> in the default logic which can then be mapped as appropriate as part of
>> implementing the trait interface.
>>
>> --
>> Jess Holle
>>
>> Mark Derricutt wrote:
>>
>> Please please please bring on traits! I'm somewhat on the fence of rather
>> seeing traits than closures in java sooner than the other.
>>
>> I'm finding LOTS of places in my code where traits would just make things
>> cleaner.
>>
>> More and more I think I just want scala :)
>>
>> On Wed, Nov 5, 2008 at 12:15 PM, hlovatt <[EMAIL PROTECTED]> wrote:
>>
>>> I thinks that Traits are a great idea for Java and judging by #215 the
>>> posse, particularly Dick, like them. I wrote about them for Java 7 in:
>>>
>>> http://www.artima.com/weblogs/viewpost.jsp?thread=220916
>>>
>>> What do you think?
>>>
>>>
>>
>> --
>> "It is easier to optimize correct code than to correct optimized code." --
>> Bill Harlan
>>
>>
>>
>>
>>
>
>
>
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
