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

[Bruno Medeiros]

kris wrote:
> 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.
> 
> 

Yes, I am so far just a student, and do not have much experience as many 
here in the NG or in the general Computer-Science/Software-Development 
population.
And yes, I often do write bluntly and in a somewhat "beacon of wisdom" tone.

But that does not mean you can immediately dismiss my comments as 
incorrect or wrong just because I am a student or write in a certain 
tone! That is a fallacy! What about actually examining what the person 
is saying? And then *debating* and debunking?

I explained and presented an argument (which could indeed be wrong) in 
my comments, but never once (until recently) did you actually comment on 
my reasoning.

Here's the funny thing. When I wrote the original post, I did have an 
example of a language that did that. It was Java, who allows covariant 
protection overriding. (C#, which I checked later than the original 
post, works with invariant protection overriding).
But I purposefully choose not to mention that, as I wanted to see how 
people (and you in particular) would react to the argument itself. And 
this is what happened...
[I generally don't like to argue things with counter-examples/analogies 
(like "it's the way it's done in X") because it usually means people 
failed to understand/agree with the "constructive" argument.]

So I hope the Java example is now enough to show that #1 is not a broken 
behavior, and I regret that my "student" argument was not enough by 
itself to show it. (or do you still think #1 is broken?) . It might not 
be the only, or the best behavior, true, but it is not broken.

Still, I am gonna withdraw some of my other statements that I now think 
are not very correct (see below). But this realization came not from any 
debunking of yours kris, but rather it occurred to me when I was 
replying to Sean.

>>>  > 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 withdraw my comment that this behavior (and thus your classes as well) 
are broken. Although protection contravariance does allow one to access 
a private function (private or other restrictive access level) from a 
context outside of the private scope (thus "breaking" the usual private 
semantics), it does not mean that the behavior as a whole is broken and 
does not make sense. One can think of it as particular exception to the 
private (or other restrictive access) level, which is a valid behavior.

It does not mean this behavior is the best, just that it is a possible 
one. But then calling it "broken" is harsh and well, incorrect. I would 
call it now "unorthodox".

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

Never once have I called you, implied, or even thought that you were a 
moron or stupid for following the D spec or designing the classes like 
that. I just said your classes had an misconception/error, but that does 
not make the class-maker an idiot. *You* are the one who implied and 
projected those insults, and frankly, that is not a very nice thing to 
do, putting bad words in other people's mouth!

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

Ok, seriously, this comment about the "other issues" I'm "either blind" 
or "choose to be sly about not mentioning them" has particularly annoyed 
me. I already stated that "#2 and #3 are clearly a bug", and then gave a 
short sentence why. What more would you like me to say and discuss about 
this other issues?! Again, this is not a rhetorical question, please 
answer, clarify me, why I'm being blind and sly about these other 
issues, and what more should I have said about them.

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