Interfaces without implementation are like a day without sunshine

Graydon Hoare graydon at
Thu Aug 24 11:38:54 PDT 2006

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

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?

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?)


More information about the Es4-discuss mailing list