I've discussed full blown inheritance with "language experts" before
(e.g. at JavaOne after various talks).
They stated that this has a really, really nasty ripple effect across
Java and would be an earth shattering change to the JVM, a huge
percentage of existing code, etc. Essentially they convinced me it's
far, far too late for this.
They were much more bullish about adding default implementation, etc, to
interfaces.
Peter Becker wrote:
> That's the same type of reasoning that lead to weird things like
> having half a dozen meanings of "virtual" in C++ or similarly bad
> overloads for "final" and "static" in Java. Squeezing different
> conceptual constructs into the same syntactic one doesn't make a
> language easier, but harder.
>
> Rather than tweaking interfaces I'd go for the full-blown multiple
> inheritance. That seems much more aligned with what Java does nowadays
> and if someone doesn't like it you can still offer them ways to avoid
> it (PMD if must, compiler-option if wanted). I don't see how adding
> multiple inheritance would be worse than adding implementations to
> interfaces.
>
> Peter
>
>
> On Thu, Nov 6, 2008 at 7:52 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
