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

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


Yes, that summarizes the problem quite nicely.  The content was never really the aim of this whole affair, as we vainly tried to point out. :P

-JJR

kris wrote:
> 
> If Walter wishes to open up the topic for input, and chooses to be frank about the original design and what his concerns are, that would make for interesting material ... we could perhaps all learn a thing or two
> 

Yes, I wish Walter would.

Kris, you have alluded to, and IIRC Sean confirmed that the docs. may have changed on this issue.

If that's the case, Walter could easily clear this up if he happens to be reading any of this (perhaps he's completely heads downs right now and isn't even aware of it; he's been known to do that once in a while :)

Anybody try pulling the old docs. from one of those online caches?

Like: http://web.archive.org/web/*/http://digitalmars.com

I don't really know exactly what to look for...

> Cheers;

On Mon, 26 Jun 2006 23:15:43 -0700, kris <foo@bar.com> wrote:
> Unfortunately that is not balanced in any manner by why the approach might be useful (not the subversion aspect!), why it might be considered more useful than one or several other alternatives, or why (for that matter) it was chosen as the model for D.

These are some of the things I'm most interested in finding out.

> But again, this whole topic is actually about broken functionality and what would appear to be quietly changing specs; not the pros and cons of one approach over another.

I realised that was your intention, however, why can't we have a discussion too? I suspect Bruno just wanted a discussion and started by giving his opinion on the 'only correct' way to do it. I'm interested in finding out what other options there are and hearing what people think the pros and cons of the various options are.

> That aspect holds little value vis-a-vis the original post, so you'll perhaps forgive me if I decline from discussing further at this time?

Sure, no worries.

> If Walter wishes to open up the topic for input, and chooses to be frank about the original design and what his concerns are, that would make for interesting material ... we could perhaps all learn a thing or two

Why wait for Walter! I'm sure everyone has an opinion about how it should work, someone might even come up with something Walter hasn't considered .. after all D is a new language with some unique properties/features, perhaps an option which isn't so good for java or C++ will be better for D, who knows!

Regan

Dave wrote:
> 
> Anybody try pulling the old docs. from one of those online caches?
> 
> Like: http://web.archive.org/web/*/http://digitalmars.com
> 
> I don't really know exactly what to look for...
> 

The doc is bundled with the dmd packages, so you can get an older DMD version and check it out. (dmd/html/d/)

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

Bruno Medeiros wrote:
> Dave wrote:
>>
>> Anybody try pulling the old docs. from one of those online caches?
>>
>> Like: http://web.archive.org/web/*/http://digitalmars.com
>>
>> I don't really know exactly what to look for...
>>
> 
> The doc is bundled with the dmd packages, so you can get an older DMD version and check it out. (dmd/html/d/)
> 

Yep, but instead of downloading old archives and scanning through them, it's much nicer to look online. The link I provided looks like a good place to look for the potentially removed documentation w.r.t. the subject of the OP.

I agree this whole discussion may have blown a bit out of proportion and usefulness. I don't mind dropping the discussion, that is except for the following quoted point.
So at the risk of being like an uptight ass, and although there likely won't be any reasonable usefulness out of it, I will consider myself personally offended if you, Kris, don't properly reply to this one:

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

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

Bruno Medeiros wrote:
>
> 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]).

Oops.  I wasn't aware that Java had this restriction.  Consider me corrected.

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

I think this statement is just poorly worded.  Private functions should be considered final with respect to their presence in the vtbl, but not with respect to whether a function of the same name may be declared in a subclass.  ie. they should be the same as non-virtual functions in C++.

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

To me, final implies that the function may not be overridden.  But for overriding to take place, the function must be visible.  If a function is private it is not visible to child classes and therefore should not be considered when sorting out overrides.  ie. all private functions are implementation details and to child classes it should be as if they simply don't exist.


Sean

On Sat, 01 Jul 2006 10:07:00 +1000, Bruno Medeiros <brunodomedeirosATgmail@SPAM.com> wrote:



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

I did and rewrote the docs for this.

  http://www.users.bigpond.com.au/ddparnell/attr.html

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

This is an example of poor English rather than anything else. A better rendition might have gone along the lines of  ....

  Functions marked as final cannot be overridden in a derived class, and marking a
  private function as final is just ignored because a private function can't
  be seen by the overriding class anyway.


-- 
Derek Parnell
Melbourne, Australia