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.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
