***** D method override mechanisms borked ****** (some more borkiness)

[Bruno Medeiros]

Sean Kelly wrote:
> Bruno Medeiros wrote:
>>
>> 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?
> 
> A constructive discussion requires the participants to entertain one 
> another's ideas in an attempt to work towards some sort of consensus.  A 
> debate, on the other hand, tends to involve dissenting opinions with 
> little attempt at conciliation.  I think what Kris meant was that your 
> delivery tends to be framed in a manner that is more suitable for a 
> debate than for a constructive discussion.  And as the purpose of this 
> thread is to clarify confusion about intended behavior, I suspect that 
> he has little interest in debating whether that behavior is or is not 
> correct in some abstract sense.  Rather, I believe, Kris is seeking a 
> consensus about intended behavior, based on experience and on the 
> language spec, and is attempting to determine whether this intent has 
> changed.  Obviously, Walter is the only one who can settle this issue. 
> And I suspect that this may become a debate later if it turns out that 
> the intent has changed without discussion :-)
> 
>> 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.
> 
> See above.  Your arguments may well have a place later if the merits of 
> this design become an issue, but for now I think it may just confuse the 
> matter.  And please note that I am not suggesting your ideas are or are 
> not completely well-founded.  As you say, other languages such as Java 
> and C++ behave the way D appears to work now.  But this is notably 
> different from how D has historically been documented and shown to behave.
> 
> 
> Sean

This thread folded into two discussions:

A) About the protection overriding issue itself.
B) About the posting behavior of me and Kris.

As for B) indeed it might not be worth to pursue this discussion any 
further (except for that one "other issues" issue I'd like to see 
settled) (And I maintain that I don't think my writing behavior was or 
is inappropriate).

As for A), well, I think there's some more things I want to mention. 
First, I agree that the spec should be clarified on the matter of how 
protection overriding is allowed to work.
Also note, you said D seems to behave as C++ and Java, but Java and C++ 
work differently. Whereas Java allow covariant overriding only, C++ 
allows (for what I've tested) for variant overriding, that is, you can 
change the protection either way (widening or strictening[this word 
spelled incorrectly]).

Second, I just noticed something in the spec that seems inconsistent or 
in error (I'm surprised that no one else mentioned this):

On http://www.digitalmars.com/d/attribute.html , Protection Attribute, 
it is said: "Private members cannot be overridden."

Seems fine to me. But on http://www.digitalmars.com/d/function.html , 
Virtual Functions, it is said: "Functions marked as final may not be 
overridden in a derived class, unless they are also private." !
What this says not only seems a clear contradiction, but also broken 
design! However, according to the following very example on that page, 
the final private method is not overridden at all, since "a.bar()" calls 
A.bar and not B.bar. In fact, there seems that there isn't any 
difference from the normal(non-final) private method in the example. So 
maybe Walter got the design right in his mind, but wrote a mistake in 
the spec there? (it seems more natural and consistent to me that final 
private methods are not at all different from private methods).Comments?

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