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

[kris]

Bruno Medeiros wrote:
> kris wrote:
>>>> 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?

Because in most of your posts you make out as though you are the "one 
and true" beacon of knowledge. But you're most certainly not: you're a 
student. It might add some credence to your perspective if you were to 
reign in your ego for a moment. This is exactly the problem with the NG 
-- people can't even make a bug report without one of a small-but-vocal 
group using it to bolter their ego. You, for example :)

A bit of humilty makes the NG a much more vibrant and useful place to be 
around. Alternatively, perhaps we should stop posting reports to the NG 
altogether.


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

As noted above, given that Walter was not interested in discussing in 
the first place, there's little point in discussing any of it now. The 
issue is reported -- you should just let it go.


>>  > 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. 

Oh, the notable condescension was palpable the first time around; again, 
the code was written to the D spec. You can imply those who followed 
said spec are outright morons for doing so, but that makes no 
difference. The fact is that the D spec *was* clear, precise, and 
followed a well-trodden path in its exposed design. The mere fact that 
/you/ don't approve of some finer points hardly matters, and doesn't 
place anyone at fault who followed said spec.


 > I'll give an example of why is that. If the original behavior allowed 
 > protection level contravariance, then we could have the following:

Indeed; and it may come as a shocking surprise that you're not the only 
one aware of some OOP fragilities. However, you paint a heavily lopsided 
picture since you're either blind to the other issues or choose to be 
sly about not mentioning them. So, though you're trying to force this 
into an NG discussion, Bruno, it's already done with until Walter asks 
for opinions.

Good luck with your exams.