That describes a particular use of "Mixin" and "Trait" (is it Ruby and
Scala resp.?) which doesn't mean you have to do it that way. For
example I don't see why using the term "mixin" would imply that the
methods get overridden in declaration order. It could well be an error
to have collisions or someone might decide on not overriding, which
means that inverse declaration order is used.
But it's just a name -- we can define it anyway we want. And if what
we want is closer to Scala's Traits than anyones Mixins then we are
probably better off calling it "traits". After all we use "closures",
too -- a term I find rather odd (and originally confusing since it has
a qutie different meaning for the mathematician in me).
Peter
On Thu, Nov 6, 2008 at 8:39 AM, hlovatt <[EMAIL PROTECTED]> 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(); }
> }
>
> 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.
> >
>
--
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 javaposse@googlegroups.com
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
-~----------~----~----~----~------~----~------~--~---
