Interfaces without implementation are like a day without sunshine

P T Withington ptw at pobox.com
Fri Oct 20 16:44:43 PDT 2006


On 2006-08-24, at 17:40 EDT, P T Withington wrote:

>> From: Graydon Hoare <graydon at mozilla.com>
>> 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.

Did anything ever happen with this idea?

We are continuing to find this a useful structuring tool, enough so  
that my users are complaining that 'interface' and 'implements' are  
the wrong terms.  They want 'interfaces with implementation' to be  
called 'traits' (because that is how they intuitively think about  
them) and that makes me realize that 'implements' should be  
'inherits' (or something similar).

I don't like the idea of having 'interfaces' _and_ 'traits'.  That  
seems overly complex.  It seems to me that an interface can be  
described just as well by a trait with required (abstract) methods.





More information about the Es4-discuss mailing list