Interfaces without implementation are like a day without sunshine
graydon at mozilla.com
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