hlovatt wrote:
> The difference between a Trait and a Mixin is that a Trait application
> is independent of order and also flat and not hierarchical (i.e. just
> like in Java with multiple interfaces), so:
>
> class C1 implements T1, T2 { ... }
>
> is the same as:
>
> class C2 implements T2, T1 { ... }
>
> This is different to a Mixin if T1 and T2 both had the same method,
> int m() say, then with a Mixin C1 would get T2's m and C2 T1's. With a
> Trait it would be an error, since it is ambiguous which one you mean
> and you would have to write:
>
> Class C implements T1, T2 { // or T2, T1 - same thing
> public int m() { return T1.super.m(); } // to get T1 behaviour
> }
>
> This has a bearing on the diamond problem. With a Trait there is no
> hierarchy so:
>
> interface T { int m() { ... } }
> interface Ta extends T { ... } // No new definition of m
> interface Tb extends T { ... } // No new definition of m
> class CTaTb implements Ta, Tb { ... } // No need to define m, it gets
> T.m
>
> and
>
> interface T1a extends T { int m() { ... } }
> class CT1aTb implements T1a, Tb { // Ambiguous, need to define m
> public int m() { return T1a.super.m(); }
>
Any closing piece of the diamond must resolve ambiguities -- and
anything below that in the hierarchy inherits these ambiguity
resolutions. [At least in any reasonable proposal I've seen.] In that
sense things are not "flat".
--
Jess Holle
> Therefore with Traits the rule is, if ambiguous it is an error that
> must be resolved explicitly by the programmer. Note the following is
> not ambiguous, since it is a single inheritance hierarchy:
>
> class CT1a implements T1a { ... } // Gets T1a.m
>
> To me the flat nature and order independence is what everyone is used
> to from Java interfaces and therefore they make a good fit (same goes
> for using the keyword interface - the behaviour is the same).
>
> On Nov 6, 8:43 am, "Peter Becker" <[EMAIL PROTECTED]> 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
>>>
>> --
>> What happened to Schroedinger's cat? My invisible saddled white dragon ate
>> it.
>>
> >
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
