Interfaces without implementation are like a day without sunshine

P T Withington ptw at
Thu Aug 24 14:40:20 PDT 2006

> From: Graydon Hoare <graydon at>
> Date: 24 August 2006 14:38:54 EDT
> P T Withington wrote:
>> What is the rationale for not permitting implementations in  
>> interfaces?
> I don't believe there's a single "killer-reason" other than the  
> basics:
>   - It would add complexity to an already complex language.

In my experience, one of the first things people ask when they learn  
about interfaces is "Why can't I put (common) state and  
implementation in them?"  It just seems a natural thing when you  
already understand classes.

>   - It's not in common use from java or C#, so programmers from
>     those backgrounds aren't likely to miss it.

And they don't know what they are missing.  :)

> Personally I don't dislike the feature, but I also think we've  
> probably way overspent our complexity budget already, and we're  
> past the self-imposed cutoff time for proposing broad features like  
> this. If others are amenable to it and think we still have any  
> wiggle room on adding things, I suppose I could be persuaded. Any  
> takers?

I would be happy to assist in any way I could.

> Currently it feels to me like one of a dozen "would be nice" things  
> we've passed over for lack of time / complexity budget reasons.
> (Side note / question: IIRC the scala designers felt it necessary  
> to include method renaming in trait inheritence, in order to avoid  
> possible name collisions. I think this had something to do with  
> preserving symmetry in the mixing of traits, rather than imposing  
> an order. I don't quite see this as a necessary aspect of the  
> proposed language feature, but perhaps I miss something. It seems  
> to me that java-style interfaces can also give rise to the same  
> sort of method-name collisions. Were they just "tidying up" a  
> failure that can happen in java, or is the situation much worse  
> under symmetric mixins?)

As I said in my reply to Jeff, mix-ins give you more rope, and with  
their restrictions they are trying to limit the length of that rope.   
My experience is that you can achieve the same effect with a careful  
programming style, so I have not adopted those restrictions in our  

More information about the Es4-discuss mailing list