***** D method override mechanisms borked ******

[Bruno Medeiros]

kris wrote:
> Bruno Medeiros wrote:
>> kris wrote:
>>
>>> Lars Ivar Igesund wrote:
>>>
>>>> kris wrote:
>>>>
>>>>
>>>>> Used to be that overriding methods in subclasses had some logic to it.
>>>>> Now? Well, who knows:
>>>>>
>>>>> 1) you can override a protected method and make it public. Doh!
>>
>> But #1 is not a bug or incorrect, see below.
>>
>>>
>>> The original behaviour limited the exposure of an overridden method 
>>> to be less than or equal to the exposure of the original. For 
>>> example, protected could not be made public via an override. The 
>>> compiler would give you an error if you attempted to do so. The 
>>> compiler used to prevent you from intercepting a superclass method 
>>> where the original intent (of the designer) was that said method 
>>> whould be internal usage only. For example, final, package, or 
>>> private methods.
>>>
>>
>> If that was the original behavior, that behavior was broken. You see, 
>> when overriding a method, limiting the protection level is unsafe, 
>> whereas widening the protection level is safe. The protection level is 
>> a call-site contract (like the return type) and as such is only safe 
>> when overridden invariantly or *covariantly*.
>>
> 
> LOL ... you might choose to state "in the research-paper entitled zzzz 
> it is noted that ....", or maybe even "language X does it this way". But 
> alas, no.
> 

Yes, I choose not to do that, and why is that a problem?


> I find it unfortunate that when reporting issues, it often gets turned 
> into a "lovefest" over one particular point whilst vaguely dispatching 
> those which clearly indicating things are broken. Almost as though 
> debunking any part of a report is viewed as a grand opportunity to 
> satiate some individual ego. Given that the apparent changes were never 
> opened up for discussion in the first place, I suspect it would be 
> foolish to partake in an open debate at this point -- concerning various 
> aspects of one philosophy over another.
> 
> So let's stay on track here: what we have is a collection of buggy 
> behaviour plus conflicting/confusing implementation rules. The 
> end-result is something pretty much guaranteed to turn people away from 
> D -- heck, I'm one of D strongest proponents, and continuing issues like 
> this are driving me away. This simply needs fixing, and it needs to 
> operate in an obvious, consistent, and dependable manner. Period.
> 

Yes, the things "which clearly indicating [they] are broken" are 
"vaguely dispatch[ed]"... isn't that natural? What else would we do 
about it? There's nothing to discuss since they are are obviously 
broken, and since it is Walter and not us who has to do the fixing, what 
else would we do about it? This not a rhetorical question, I would 
really like to know why you find it unfortunate that these things are 
"vaguely dispatch[ed]". I am not dismissing the importance of what needs 
to be fixed (and I'm sure #2 and #3 will) because I'm silent about it.

And as for the things that are not so clearly broken (i.e., which may 
not be broken at all), yes those are the ones who are "debunked". 
Because if one is asking to fix something that is not broken, then that 
adds noise to the information and reports Walter's receives, and overall 
difficults his job. Wouldn't you agree?

> 
>  > If you designed your classes around that original behavior, they're 
> broken.
> 
> Indeed they are. They were designed in strict accordance to the written 
> D spec. Sean notes that certain original parts of the spec have now 
> somehow silently disappeared ... no mention of such fundamental change 
> was ever apparently announced or discussed.
> 

I meant your classes themselves, their design and conception, not your 
classes running on some implementation. I'll give an example of why is 
that. If the original behavior allowed protection level contravariance, 
then we could have the following:

   class Foo {
     public void func() { writefln("Foo.func"); }
   }

   class FooBar : Foo {
     override private void func() { writefln("private FooBar.func"); }
   }
...
   Foo foobar = new FooBar();
   foobar.func();  // FooBar.func is executed, despite being private

And so that behaviour is broken.

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D