This is only partially true with Traits, consider:
interface T { int m() { ... } }
interface T1a extends T { int m() { ... } }
interface Tb extends T { ... } // No new definition of m
class CT1aTb implements T1a, Tb { // Ambiguous, need to define m
public int m() { return T1a.super.m(); }
}
class D extends CT1aTb { ... } // No need to define m
But
class DT extends D implements T { // Now ambiguous
public int m() { ... }
}
Traits would require the additional clarification once ambiguity was
re-introduced by applying a Trait, T, with a definition of m to D,
even though D already defines m.
On Nov 6, 9:43 am, Jess Holle <[EMAIL PROTECTED]> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
