www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - ***** D method override mechanisms borked ******

reply kris <foo bar.com> writes:
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!

2) you can override a public method and make it private ... ok, but get 
this -- the overload is not virtual -- it doesn't "actually" overload at 
all. Very sneaky bug in the making, especially when the base class is 
altered just slightly.

3) to fix #2 let's use the override keyword! Yay! That will ensure we're 
actually overriding the base class method instance! Well, it compiles, 
but does *not* override. Bork Bork Bork.

And so on, ad infinitum.

This was not a problem at some distant point in the past. Now the rules 
are (a) too murky for this simple dude to even comprehend and (b) 
apparently thoroughly broken. The behaviour turns D into a land-mine for 
both the unwary and for the seasoned professional. How to turn people 
away from D in one easy lesson.

Please, please, please revert whatever cleverness was injected there and 
make it work in a clear, precise, /obvious/, and above all, *dependable* 
manner. Heck, make the "override" keyword mandatory if you need to. The 
latter should at least work, or cause a compie-time error.
Jun 24 2006
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
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!
 
 2) you can override a public method and make it private ... ok, but get
 this -- the overload is not virtual -- it doesn't "actually" overload at
 all. Very sneaky bug in the making, especially when the base class is
 altered just slightly.
 
 3) to fix #2 let's use the override keyword! Yay! That will ensure we're
 actually overriding the base class method instance! Well, it compiles,
 but does *not* override. Bork Bork Bork.
 
 And so on, ad infinitum.
 
 This was not a problem at some distant point in the past. Now the rules
 are (a) too murky for this simple dude to even comprehend and (b)
 apparently thoroughly broken. The behaviour turns D into a land-mine for
 both the unwary and for the seasoned professional. How to turn people
 away from D in one easy lesson.
 
 Please, please, please revert whatever cleverness was injected there and
 make it work in a clear, precise, /obvious/, and above all, *dependable*
 manner. Heck, make the "override" keyword mandatory if you need to. The
 latter should at least work, or cause a compie-time error.

I couldn't agree more, and make sure the rules are thouroughly documented! -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jun 24 2006
next sibling parent John Reimer <terminal.node gmail.com> writes:
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!

 2) you can override a public method and make it private ... ok, but get
 this -- the overload is not virtual -- it doesn't "actually" overload at
 all. Very sneaky bug in the making, especially when the base class is
 altered just slightly.

 3) to fix #2 let's use the override keyword! Yay! That will ensure we're
 actually overriding the base class method instance! Well, it compiles,
 but does *not* override. Bork Bork Bork.

 And so on, ad infinitum.

 This was not a problem at some distant point in the past. Now the rules
 are (a) too murky for this simple dude to even comprehend and (b)
 apparently thoroughly broken. The behaviour turns D into a land-mine for
 both the unwary and for the seasoned professional. How to turn people
 away from D in one easy lesson.

 Please, please, please revert whatever cleverness was injected there and
 make it work in a clear, precise, /obvious/, and above all, *dependable*
 manner. Heck, make the "override" keyword mandatory if you need to. The
 latter should at least work, or cause a compie-time error.

I couldn't agree more, and make sure the rules are thouroughly documented!

Agree... Please fix! (yes, another "me, too" post, but I'm hoping this helps get Walter's attention). -JJR
Jun 24 2006
prev sibling parent reply kris <foo bar.com> writes:
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!

2) you can override a public method and make it private ... ok, but get
this -- the overload is not virtual -- it doesn't "actually" overload at
all. Very sneaky bug in the making, especially when the base class is
altered just slightly.

3) to fix #2 let's use the override keyword! Yay! That will ensure we're
actually overriding the base class method instance! Well, it compiles,
but does *not* override. Bork Bork Bork.

And so on, ad infinitum.

This was not a problem at some distant point in the past. Now the rules
are (a) too murky for this simple dude to even comprehend and (b)
apparently thoroughly broken. The behaviour turns D into a land-mine for
both the unwary and for the seasoned professional. How to turn people
away from D in one easy lesson.

Please, please, please revert whatever cleverness was injected there and
make it work in a clear, precise, /obvious/, and above all, *dependable*
manner. Heck, make the "override" keyword mandatory if you need to. The
latter should at least work, or cause a compie-time error.

I couldn't agree more, and make sure the rules are thouroughly documented!

Before Bruno gives me a ticket for terminology abuse, I should note that the use of "overload" in #2 was completely unintentional. One should at least wake up properly before getting one's daily dose of D frustration. I seriously hope this is all just a mistake/bug/whatever, which will be fixed quickly and appropriately. However ... 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. Now, you can intercept all you like. The compiler does not give an error at all. The following example illustrates a litany of places where the compiler should halt. Just ask yourself how one is supposed to design superclass functionality that should not be exposed, overridden or otherwise subverted by a subclass? extern(C) int printf (char*, ...); class Super { protected void fu() { printf ("super fu\n"); } package void bar() { printf ("super bar\n"); } private void snafu() { printf ("super snafu\n"); } private void fu1() { printf ("super fu\n"); } final void bar1() { printf ("super bar\n"); } final private void snafu1() { printf ("super snafu\n"); } } class Sub : Super { // illegal: exposing a protected method public void fu() { printf ("sub fu\n"); } // illegal: exposing a package method public void bar() { printf ("sub bar\n"); } // illegal: exposing a private method public void snafu() { printf ("sub snafu\n"); } // illegal: "override" a private method private override void fu1() { printf ("sub fu1\n"); } // illegal: "override" a final method private override void bar1() { printf ("sub bar1\n"); } // illegal: override & expose a final private method public void snafu1() { printf ("sub snafu1\n"); } } void main() { auto s = new Sub; s.fu; s.bar; s.snafu; s.fu1; s.bar1; s.snafu1; } output: sub fu sub bar sub snafu sub fu1 sub bar1 sub snafu1 Basically, several well-known and fundamental OO tenets no longer exist in D; I personally have over two years of carefully designed libraries that are now little more than trash because of this (any subclass can now intercept any type of method implementation). Would imagine others are in the same boat. Anyone who's ever tried to provide "read only" or immutable class implementation, particularly to make multi-threaded code so much more deterministic, can kiss that goodbye ... let's all wave together :/
Jun 24 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
kris wrote:
 
 Basically, several well-known and fundamental OO tenets no longer exist 
 in D; I personally have over two years of carefully designed libraries 
 that are now little more than trash because of this (any subclass can 
 now intercept any type of method implementation). Would imagine others 
 are in the same boat.

This simply has to be a bug, as I can't imagine such a fundamental change occurring both intentionally and silently. It strikes me as odd, however, that the language I remember in the spec concerning this seems absent. It was in the "function inheritance and overriding" section, wasn't it? At the very least, I remember quite clearly that private functions were not meant to be overridden by a base class, which contradicts the results of your example. Perhaps a new ticket should be opened for this? Sean
Jun 24 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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!

 2) you can override a public method and make it private ... ok, but get
 this -- the overload is not virtual -- it doesn't "actually" overload at
 all. Very sneaky bug in the making, especially when the base class is
 altered just slightly.

 3) to fix #2 let's use the override keyword! Yay! That will ensure we're
 actually overriding the base class method instance! Well, it compiles,
 but does *not* override. Bork Bork Bork.

 And so on, ad infinitum.

 This was not a problem at some distant point in the past. Now the rules
 are (a) too murky for this simple dude to even comprehend and (b)
 apparently thoroughly broken. The behaviour turns D into a land-mine for
 both the unwary and for the seasoned professional. How to turn people
 away from D in one easy lesson.

 Please, please, please revert whatever cleverness was injected there and
 make it work in a clear, precise, /obvious/, and above all, *dependable*
 manner. Heck, make the "override" keyword mandatory if you need to. The
 latter should at least work, or cause a compie-time error.

I couldn't agree more, and make sure the rules are thouroughly documented!


 I seriously hope this is all just a mistake/bug/whatever, which will be 
 fixed quickly and appropriately. However ...

#2 and #3 are clearly a bug, both because override must *always* override, and because " Private members cannot be overridden" (http://www.digitalmars.com/d/attribute.html). 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*. If you designed your classes around that original behavior, they're broken.
 Now, you can intercept all you like. The compiler does not give an error 
 at all. The following example illustrates a litany of places where the 
 compiler should halt. Just ask yourself how one is supposed to design 
 superclass functionality that should not be exposed, overridden or 
 otherwise subverted by a subclass?
 
 
 extern(C) int printf (char*, ...);
 ...

As per what I said above, some of those examples are not incorrect. The others are.
 Before Bruno gives me a ticket for terminology abuse, I should note that
 the use of "overload" in #2 was completely unintentional. One should at
 least wake up properly before getting one's daily dose of D frustration.

No problem if it was unintentional. ;) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 25 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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*. If you designed your classes around that original behavior, they're broken.

I'm not sure I agree. However, if overriding behaves this way then it makes sense that aliasing should as well, and I would be surprised if aliasing ever behaved this way. Perhaps this is one area where one should rely on programming style and not on the compiler? Sean
Jun 25 2006
parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
Sean Kelly 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*. If you designed your classes around that original behavior, they're broken.

I'm not sure I agree. However, if overriding behaves this way then it makes sense that aliasing should as well, and I would be surprised if aliasing ever behaved this way. Perhaps this is one area where one should rely on programming style and not on the compiler? Sean

Not sure you agree with what exactly? There is no discussion to what kind of overriding is "protection safe" or not. Still, as for what the language behavior should be, that's arguable (but I didn't comment on that). For instance, one could allow covariant protection levels, that's the behavior of Java. But even though it is safe, I do find it a bit odd in practice. One could allow invariant protection levels only (that's the behavior of C#). And even contravariant protection levels, although not "protection safe", is actually a behavior that can have a certain sense. (calling it broken was perhaps inadequate) -- Bruno Medeiros - CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Jun 26 2006
prev sibling parent reply kris <foo bar.com> writes:
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. 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.
 If you designed your classes around that original behavior, they're 

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.
Jun 25 2006
parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 26 2006
parent reply kris <foo bar.com> writes:
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.
Jun 26 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
Why mention Bruno is a student? What difference does it make?

I don't know a lot about the issues around overriding protection and would  
be interested to hear why you think Bruno is wrong in his comments because  
what he has said so far (you've implied he's ignoring some issues, what  
issues?) makes sense to me.

I get the impression you're not interested in discussing it, which is  
fine, can someone else illuminate it for me?

Regan
Jun 26 2006
parent reply John Reimer <terminal.node gmail.com> writes:
Regan Heath wrote:
 Why mention Bruno is a student? What difference does it make?
 
 I don't know a lot about the issues around overriding protection and 
 would be interested to hear why you think Bruno is wrong in his comments 
 because what he has said so far (you've implied he's ignoring some 
 issues, what issues?) makes sense to me.
 
 I get the impression you're not interested in discussing it, which is 
 fine, can someone else illuminate it for me?
 
 Regan

Kris actually voiced some of the feelings I've been experiencing about Bruno's posts. It's hard to articulate that kind of "feeling." But for the most part, I feel he's accurate in his complaint (although he sounds a little exasperated). Bruno does come across extremely confident, and while "ego" is a strong word, Bruno has given us very little indication that his posts are an expression of anything other than that. So that leaves us thinking one of two things: either he really knows what he's talking about and likes bombarding the community with statements of absolute truth, despite the fact that nobody really knows why he thinks he knows (like maybe many long years of research, experience, and study?) ; or he's a 21 year old college kid who is quite bright, but has a penchant for talking about what's right and wrong about everything as if his is the final word on the matter. Either way, there's no common courtesy or deference to the experience of others, many of whom may have a whole lot more years behind them in the computer industry. There's no gentle discussion. There's just strident confidence about how things are with little justification for it or evidence as to why. This world is full of gray areas and full of systems that try to make an organized approach to understanding and working in them, but that doesn't make any one system perfect. As time goes on, we find that out. Regan, It's less about his being a student, which as you say really makes no difference, and more about how he voices his opinions with very little reason for us to know why his word should be law on matters. The student thing comes up because that's about the only portrait Bruno has bothered to paint for us (his signature). And I'm afraid that portrait is rather lacking in any substance. Regan, you've been in the same spot as Bruno, I think, and perhaps empathize with him a little, especially in relation to dealing with Kris :). But you've doggedly persisted through, developed D code, contributed to the community in significant ways and thus earned that amount of respect you now deserve. But there were times when people were annoyed with your innate ability to start long-winded debates on things. Some of your opinions came across the same way. When youth speak with so such confidence, it tends to come across as abrasive, annoying, and egotistical, no matter what the original intention may be. I'm giving Bruno the benefit of the doubt. He probably just enjoys D, this community, and the language related discussions so much, that he has trouble holding back. That's nice... but there are consequences to any action lacking self-control. :) -JJR
Jun 26 2006
next sibling parent reply "Regan Heath" <regan netwin.co.nz> writes:
On Mon, 26 Jun 2006 16:27:08 -0700, John Reimer <terminal.node gmail.com>  
wrote:
 Regan Heath wrote:
 Why mention Bruno is a student? What difference does it make?
  I don't know a lot about the issues around overriding protection and  
 would be interested to hear why you think Bruno is wrong in his  
 comments because what he has said so far (you've implied he's ignoring  
 some issues, what issues?) makes sense to me.
  I get the impression you're not interested in discussing it, which is  
 fine, can someone else illuminate it for me?
  Regan

Kris actually voiced some of the feelings I've been experiencing about Bruno's posts. It's hard to articulate that kind of "feeling." But for the most part, I feel he's accurate in his complaint (although he sounds a little exasperated). Bruno does come across extremely confident, and while "ego" is a strong word, Bruno has given us very little indication that his posts are an expression of anything other than that. So that leaves us thinking one of two things: either he really knows what he's talking about and likes bombarding the community with statements of absolute truth, despite the fact that nobody really knows why he thinks he knows (like maybe many long years of research, experience, and study?) ; or he's a 21 year old college kid who is quite bright, but has a penchant for talking about what's right and wrong about everything as if his is the final word on the matter. Either way, there's no common courtesy or deference to the experience of others, many of whom may have a whole lot more years behind them in the computer industry. There's no gentle discussion. There's just strident confidence about how things are with little justification for it or evidence as to why. This world is full of gray areas and full of systems that try to make an organized approach to understanding and working in them, but that doesn't make any one system perfect. As time goes on, we find that out. Regan, It's less about his being a student, which as you say really makes no difference, and more about how he voices his opinions with very little reason for us to know why his word should be law on matters. The student thing comes up because that's about the only portrait Bruno has bothered to paint for us (his signature). And I'm afraid that portrait is rather lacking in any substance. Regan, you've been in the same spot as Bruno, I think, and perhaps empathize with him a little, especially in relation to dealing with Kris :). But you've doggedly persisted through, developed D code, contributed to the community in significant ways and thus earned that amount of respect you now deserve. But there were times when people were annoyed with your innate ability to start long-winded debates on things. Some of your opinions came across the same way. When youth speak with so such confidence, it tends to come across as abrasive, annoying, and egotistical, no matter what the original intention may be. I'm giving Bruno the benefit of the doubt. He probably just enjoys D, this community, and the language related discussions so much, that he has trouble holding back. That's nice... but there are consequences to any action lacking self-control. :)

I tend to agree with a lot (perhaps all) or what you've said above. I do empathise with Bruno, he's obviously confident in his own knowledge and opinion, as I think many people are. He's also blunt and direct in expressing that opinion, as I can be. I have been in his position and what I needed in that position was discussion on the topic to either cement my ideas/thoughts or to discover new ideas (like those that Kris alluded to here) which would later change my opinion. I've learnt a lot from this newsgroup, despite having 7 odd years of programming experience (which isnt a lot compared to some here I know). I don't think anyone, regardless of experience, should stop learning, and this newsgroup is a very good place to learn. So, all I'm asking is for someone, who knows what Kris was alluding to, to explain it to me cos I can't see anything wrong (factually) with what Bruno has said so far. :) Regan
Jun 26 2006
parent reply kris <foo bar.com> writes:
Regan Heath wrote:
 On Mon, 26 Jun 2006 16:27:08 -0700, John Reimer 
 <terminal.node gmail.com>  wrote:
 
 Regan Heath wrote:

 Why mention Bruno is a student? What difference does it make?
  I don't know a lot about the issues around overriding protection 
 and  would be interested to hear why you think Bruno is wrong in his  
 comments because what he has said so far (you've implied he's 
 ignoring  some issues, what issues?) makes sense to me.
  I get the impression you're not interested in discussing it, which 
 is  fine, can someone else illuminate it for me?
  Regan

Kris actually voiced some of the feelings I've been experiencing about Bruno's posts. It's hard to articulate that kind of "feeling." But for the most part, I feel he's accurate in his complaint (although he sounds a little exasperated). Bruno does come across extremely confident, and while "ego" is a strong word, Bruno has given us very little indication that his posts are an expression of anything other than that. So that leaves us thinking one of two things: either he really knows what he's talking about and likes bombarding the community with statements of absolute truth, despite the fact that nobody really knows why he thinks he knows (like maybe many long years of research, experience, and study?) ; or he's a 21 year old college kid who is quite bright, but has a penchant for talking about what's right and wrong about everything as if his is the final word on the matter. Either way, there's no common courtesy or deference to the experience of others, many of whom may have a whole lot more years behind them in the computer industry. There's no gentle discussion. There's just strident confidence about how things are with little justification for it or evidence as to why. This world is full of gray areas and full of systems that try to make an organized approach to understanding and working in them, but that doesn't make any one system perfect. As time goes on, we find that out. Regan, It's less about his being a student, which as you say really makes no difference, and more about how he voices his opinions with very little reason for us to know why his word should be law on matters. The student thing comes up because that's about the only portrait Bruno has bothered to paint for us (his signature). And I'm afraid that portrait is rather lacking in any substance. Regan, you've been in the same spot as Bruno, I think, and perhaps empathize with him a little, especially in relation to dealing with Kris :). But you've doggedly persisted through, developed D code, contributed to the community in significant ways and thus earned that amount of respect you now deserve. But there were times when people were annoyed with your innate ability to start long-winded debates on things. Some of your opinions came across the same way. When youth speak with so such confidence, it tends to come across as abrasive, annoying, and egotistical, no matter what the original intention may be. I'm giving Bruno the benefit of the doubt. He probably just enjoys D, this community, and the language related discussions so much, that he has trouble holding back. That's nice... but there are consequences to any action lacking self-control. :)

I tend to agree with a lot (perhaps all) or what you've said above. I do empathise with Bruno, he's obviously confident in his own knowledge and opinion, as I think many people are. He's also blunt and direct in expressing that opinion, as I can be. I have been in his position and what I needed in that position was discussion on the topic to either cement my ideas/thoughts or to discover new ideas (like those that Kris alluded to here) which would later change my opinion.

Hey, Regan;
 
 I've learnt a lot from this newsgroup, despite having 7 odd years of  
 programming experience (which isnt a lot compared to some here I know). 
 I  don't think anyone, regardless of experience, should stop learning, 

so very true
 and  this newsgroup is a very good place to learn.

It certainly is when information is tendered in a genuine manner
 So, all I'm asking is for someone, who knows what Kris was alluding to, 
 to  explain it to me cos I can't see anything wrong (factually) with 
 what  Bruno has said so far. :)

That's because the single point made is not factually incorrect; nor was it ever claimed to be. Instead there's a bit of the "Shock & Awe" aspect lurking there. Half-truths are often worse than nonsense. Briefly, that vague example is showing how one can purposely subvert the compiler ~ a good way to attach negative connotation to anything. 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. IMO, one of the hardest things to do in this realm is coming up with a good compromise. FWIW, I feel D is an unusually well-considered language ... Walter's long experience clearly shows up in the good parts, and I rather suspect D would be a shadow of itself if the ability to carefully balance various compromises was not well-formed. That doesn't always work, as we've seen, but it's needed as a foundation. Perhaps you get my drift here? 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. 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? 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 Cheers;
Jun 26 2006
next sibling parent reply Dave <Dave_member pathlink.com> writes:
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;

Jun 27 2006
next sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 27 2006
parent Dave <Dave_member pathlink.com> writes:
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.
Jun 27 2006
prev sibling parent jcc7 <jcc7_member pathlink.com> writes:
In article <e7sa0h$3no$1 digitaldaemon.com>, Dave says...
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.

Does Walter still read this newsgroup? I know that I don't read it as much as I used to now that it's mostly automated posts from bugzilla. ;) (He might just hang out in bugzilla itself and ignore this newsgroup.) Aside from the politics of personal destruction (which I try not to participate in), this discussion has been way over my head. It sounds like an important issue, but it seems like it'd fit in more over at the main D newsgroup than in the bugs newsgroup. The specification secretly changed in the middle of the night? Important parts of the spec have been quietly deleted? Maybe the Digital Mars website has been broken into by Microsoft, and Walter has been replaced by a clone created by the Sun Corporation. Sounds like something the broader D community would be interested in finding out about.
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 :)

Maybe he's unaware of this discussion. Maybe he's ignoring it. There's no way to know for sure.
Anybody try pulling the old docs. from one of those online caches?

Some unofficial PDF snapshots are available, too: http://www.prowiki.org/wiki4d/wiki.cgi?LanguageSpecification jcc7
Jul 06 2006
prev sibling parent "Regan Heath" <regan netwin.co.nz> writes:
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
Jun 27 2006
prev sibling parent reply Carlos Santander <csantander619 gmail.com> writes:
John Reimer escribió:
 Regan Heath wrote:
 Why mention Bruno is a student? What difference does it make?

 I don't know a lot about the issues around overriding protection and 
 would be interested to hear why you think Bruno is wrong in his 
 comments because what he has said so far (you've implied he's ignoring 
 some issues, what issues?) makes sense to me.

 I get the impression you're not interested in discussing it, which is 
 fine, can someone else illuminate it for me?

 Regan

Kris actually voiced some of the feelings I've been experiencing about Bruno's posts. It's hard to articulate that kind of "feeling." But for the most part, I feel he's accurate in his complaint (although he sounds a little exasperated). Bruno does come across extremely confident, and while "ego" is a strong word, Bruno has given us very little indication that his posts are an expression of anything other than that. So that leaves us thinking one of two things: either he really knows what he's talking about and likes bombarding the community with statements of absolute truth, despite the fact that nobody really knows why he thinks he knows (like maybe many long years of research, experience, and study?) ; or he's a 21 year old college kid who is quite bright, but has a penchant for talking about what's right and wrong about everything as if his is the final word on the matter. Either way, there's no common courtesy or deference to the experience of others, many of whom may have a whole lot more years behind them in the computer industry. There's no gentle discussion. There's just strident confidence about how things are with little justification for it or evidence as to why. This world is full of gray areas and full of systems that try to make an organized approach to understanding and working in them, but that doesn't make any one system perfect. As time goes on, we find that out. Regan, It's less about his being a student, which as you say really makes no difference, and more about how he voices his opinions with very little reason for us to know why his word should be law on matters. The student thing comes up because that's about the only portrait Bruno has bothered to paint for us (his signature). And I'm afraid that portrait is rather lacking in any substance. Regan, you've been in the same spot as Bruno, I think, and perhaps empathize with him a little, especially in relation to dealing with Kris :). But you've doggedly persisted through, developed D code, contributed to the community in significant ways and thus earned that amount of respect you now deserve. But there were times when people were annoyed with your innate ability to start long-winded debates on things. Some of your opinions came across the same way. When youth speak with so such confidence, it tends to come across as abrasive, annoying, and egotistical, no matter what the original intention may be. I'm giving Bruno the benefit of the doubt. He probably just enjoys D, this community, and the language related discussions so much, that he has trouble holding back. That's nice... but there are consequences to any action lacking self-control. :) -JJR

I think Kris overreacted. Maybe he was right, but I don't think that was the right way to express it. Experience is a very valuable thing, granted, but maybe Bruno has experience and he just hasn't made it public. But whether that's the case or not, I agree with Regan in that it shouldn't matter that much. And if you, Kris, think Bruno needs a bit of "enlightenment", why not explain him a bit? The rest of us could use that help too. Anyway, I hope it was just a bit of frustration and we can leave it there. -- Carlos Santander Bernal
Jun 26 2006
next sibling parent reply kris <foo bar.com> writes:
Carlos Santander wrote:
 John Reimer escribió:
 Kris actually voiced some of the feelings I've been experiencing about 
 Bruno's posts.  It's hard to articulate that kind of "feeling." But 
 for the most part, I feel he's accurate in his complaint (although he 
 sounds a little exasperated).

 Bruno does come across extremely confident, and while "ego" is a 
 strong word,  Bruno has given us very little indication that his posts 
 are an expression of anything other than that.  So that leaves us 
 thinking one of two things: either he really knows what he's talking 
 about and likes bombarding the community with statements of absolute 
 truth, despite the fact that nobody really knows why he thinks he 
 knows (like maybe many long years of research, experience, and study?) 
 ; or he's a 21 year old college kid who is quite bright, but has a 
 penchant for talking about what's right and wrong about everything as 
 if his is the final word on the matter.

 Either way, there's no common courtesy or deference to the experience 
 of  others, many of whom may have a whole lot more years behind them 
 in the computer industry. There's no gentle discussion. There's just 
 strident confidence about how things are with little justification for 
 it or evidence as to why. This world is full of gray areas and full of 
 systems that try to make an organized approach to understanding and 
 working in them, but that doesn't make any one system perfect.  As 
 time goes on, we find that out.

 Regan, It's less about his being a student, which as you say really 
 makes no difference, and more about how he voices his opinions with 
 very little reason for us to know why his word should be law on 
 matters.  The student thing comes up because that's about the only 
 portrait Bruno has bothered to paint for us (his signature).  And I'm 
 afraid that portrait is rather lacking in any substance.

 Regan, you've been in the same spot as Bruno, I think, and perhaps 
 empathize with him a little, especially in relation to dealing with 
 Kris :).  But you've doggedly persisted through, developed D code, 
 contributed to the community in significant ways and thus earned that 
 amount of respect you now deserve.  But there were times when people 
 were annoyed with your innate ability to start long-winded debates on 
 things. Some of your opinions came across the same way.

 When youth speak with so such confidence, it tends to come across as 
 abrasive, annoying, and egotistical, no matter what the original 
 intention may be.

 I'm giving Bruno the benefit of the doubt.  He probably just enjoys D, 
 this community, and the language related discussions so much, that he 
 has trouble holding back.  That's nice... but there are consequences 
 to any action lacking self-control. :)

 -JJR

I think Kris overreacted. Maybe he was right, but I don't think that was the right way to express it. Experience is a very valuable thing, granted, but maybe Bruno has experience and he just hasn't made it public. But whether that's the case or not, I agree with Regan in that it shouldn't matter that much.

You're right, Carlos; it does not matter that much. My point was simply that Bruno's long-standing behaviour of "correcting" every little detail, and his particular approach to doing so, is often out of step with his reality. That does *not* mean the information he passes along is wrong; nor does it mean it is right. Most things in the world can be considered right or wrong, given different circumstances. You can visit Bruno's website where he talks about himself: the url is attached to each of his posts. You'll discover one 22 year old CS student. My prior comment was not to suggest students are somehow unknowlegable -- not in the least -- those lucky people tend to have a lot of time to peruse the literature and learn. At least, it was the task given to me at that time. And who knows; maybe Bruno is a true genius. Instead, as has been pointed out, these persistent "corrections" are often couched in less than favourable terms. To put this into perspective: let's suppose for a moment that you, Carlos, had spent significant effort designing and writing for the benefit of the community. Let's also suppose that the language spec silently changed and "broke" your designs somewhat. Finally, let's suppose you post a report about those things which are broken, and then this guy Kris comes along and says something like the following: "Pah! How stupid to follow the spec, or even the long-term language behaviour when, as I will tell you, *I* know how it should have been done in the first place. You see, you can thank only yourself for your broken design" Well, gee - what a complete arsehole. Doesn't matter whether I'm an arrogant student, an arrogant professor, or an arrogant policeman. Thus, the student comment should be taken within context. Certainly was not meant as an offence to students. Of course, there will probably be those who suspect I am just sensitive to any kind of criticism. All I can say is, if that were an issue, I would hardly be publishing code. It's a bit of a shame more people don't do that. What get's my goat is this ~ and it's something to think about ~ there's a world of difference between genuinely trying to impart knowledge, and simply wielding it like a hefty club
Jun 26 2006
parent reply Carlos Santander <csantander619 gmail.com> writes:
kris escribió:
 Carlos Santander wrote:
 John Reimer escribió:
 Kris actually voiced some of the feelings I've been experiencing 
 about Bruno's posts.  It's hard to articulate that kind of "feeling." 
 But for the most part, I feel he's accurate in his complaint 
 (although he sounds a little exasperated).

 Bruno does come across extremely confident, and while "ego" is a 
 strong word,  Bruno has given us very little indication that his 
 posts are an expression of anything other than that.  So that leaves 
 us thinking one of two things: either he really knows what he's 
 talking about and likes bombarding the community with statements of 
 absolute truth, despite the fact that nobody really knows why he 
 thinks he knows (like maybe many long years of research, experience, 
 and study?) ; or he's a 21 year old college kid who is quite bright, 
 but has a penchant for talking about what's right and wrong about 
 everything as if his is the final word on the matter.

 Either way, there's no common courtesy or deference to the experience 
 of  others, many of whom may have a whole lot more years behind them 
 in the computer industry. There's no gentle discussion. There's just 
 strident confidence about how things are with little justification 
 for it or evidence as to why. This world is full of gray areas and 
 full of systems that try to make an organized approach to 
 understanding and working in them, but that doesn't make any one 
 system perfect.  As time goes on, we find that out.

 Regan, It's less about his being a student, which as you say really 
 makes no difference, and more about how he voices his opinions with 
 very little reason for us to know why his word should be law on 
 matters.  The student thing comes up because that's about the only 
 portrait Bruno has bothered to paint for us (his signature).  And I'm 
 afraid that portrait is rather lacking in any substance.

 Regan, you've been in the same spot as Bruno, I think, and perhaps 
 empathize with him a little, especially in relation to dealing with 
 Kris :).  But you've doggedly persisted through, developed D code, 
 contributed to the community in significant ways and thus earned that 
 amount of respect you now deserve.  But there were times when people 
 were annoyed with your innate ability to start long-winded debates on 
 things. Some of your opinions came across the same way.

 When youth speak with so such confidence, it tends to come across as 
 abrasive, annoying, and egotistical, no matter what the original 
 intention may be.

 I'm giving Bruno the benefit of the doubt.  He probably just enjoys 
 D, this community, and the language related discussions so much, that 
 he has trouble holding back.  That's nice... but there are 
 consequences to any action lacking self-control. :)

 -JJR

I think Kris overreacted. Maybe he was right, but I don't think that was the right way to express it. Experience is a very valuable thing, granted, but maybe Bruno has experience and he just hasn't made it public. But whether that's the case or not, I agree with Regan in that it shouldn't matter that much.

You're right, Carlos; it does not matter that much. My point was simply that Bruno's long-standing behaviour of "correcting" every little detail, and his particular approach to doing so, is often out of step with his reality. That does *not* mean the information he passes along is wrong; nor does it mean it is right. Most things in the world can be considered right or wrong, given different circumstances. You can visit Bruno's website where he talks about himself: the url is attached to each of his posts. You'll discover one 22 year old CS student. My prior comment was not to suggest students are somehow unknowlegable -- not in the least -- those lucky people tend to have a lot of time to peruse the literature and learn. At least, it was the task given to me at that time. And who knows; maybe Bruno is a true genius. Instead, as has been pointed out, these persistent "corrections" are often couched in less than favourable terms. To put this into perspective: let's suppose for a moment that you, Carlos, had spent significant effort designing and writing for the benefit of the community. Let's also suppose that the language spec silently changed and "broke" your designs somewhat. Finally, let's suppose you post a report about those things which are broken, and then this guy Kris comes along and says something like the following: "Pah! How stupid to follow the spec, or even the long-term language behaviour when, as I will tell you, *I* know how it should have been done in the first place. You see, you can thank only yourself for your broken design" Well, gee - what a complete arsehole. Doesn't matter whether I'm an arrogant student, an arrogant professor, or an arrogant policeman. Thus, the student comment should be taken within context. Certainly was not meant as an offence to students. Of course, there will probably be those who suspect I am just sensitive to any kind of criticism. All I can say is, if that were an issue, I would hardly be publishing code. It's a bit of a shame more people don't do that. What get's my goat is this ~ and it's something to think about ~ there's a world of difference between genuinely trying to impart knowledge, and simply wielding it like a hefty club

This is to both your and John's replies, let's just leave it there. Both of you made good points but it doesn't help anyone to keep this going. -- Carlos Santander Bernal
Jun 27 2006
parent kris <foo bar.com> writes:
Carlos Santander wrote:
 kris escribió:
 This is to both your and John's replies, let's just leave it there. Both 
 of you made good points but it doesn't help anyone to keep this going.

Aye;
Jun 27 2006
prev sibling parent John Reimer <terminal.node gmail.com> writes:
Carlos Santander wrote:
 
 I think Kris overreacted. Maybe he was right, but I don't think that was 
 the right way to express it. Experience is a very valuable thing, 
 granted, but maybe Bruno has experience and he just hasn't made it 
 public. But whether that's the case or not, I agree with Regan in that 
 it shouldn't matter that much. And if you, Kris, think Bruno needs a bit 
 of "enlightenment", why not explain him a bit? The rest of us could use 
 that help too.
 
 Anyway, I hope it was just a bit of frustration and we can leave it there.
 

Carlos said: "But whether that's the case or not, I agree with Regan in that it shouldn't matter that much." Actually, Carlos, I beg to disagree. Experience is everything (and especially, may I add, experience using D past and present). Because if Bruno doesn't have it and ends up just voicing what he reads... and voices it in the "conclusive" manner that he does... well it just amounts to the same thing as someone being handed a loudspeaker and a script... and perhaps is just as annoying. Furthermore, being blunt and direct in expressing an opinion is not always the wisest route to go: if it is the chosen route, it better be very carefully measured. If one wants to learn and grow in a community, especially as a 22 year old CS student, then flatly stating somebody is wrong in a matter is probably the worst approach: 1. It is probably the fastest way to offend and cause a discussion to vier into coarse waters. 2. It is presumptuous without fully understanding the persons experience and point of view. As an object lesson, I suggest Bruno go and learn who Kris is and how long and hard he's worked with D over the years. Read his posts from the old D group and then later in this one. In this regard, Bruno really made no acknowledgment of Kris' experience with evolving D features. And nor did he show any interest to learn about them. It was like "so what?" Bruno, for your own sake, and to ensure continued valued participation in here, please treat long time D contributers with more respect than you have been (well treat everyone with respect, actually). Some of these people have been around for a long time, know D inside and out, have done more programming in the language than even Walter himself, and have contributed much to what D has become today. Bruno, You are totally out of line. And all others that say that loud and blunt contradiction should be the natural mode of progressive learning and discussion in the D newsgroup are confused. Why am I and others jumping on Bruno like this? I hope he understands that this is a courtesy to keep him from being completely ignored, filtered, or constantly chastised. Carlos, this is not against you at all; I've always found you respectful and your posts easy to read even when you stated your opinions most earnestly. I just wanted to explain, as best as I could, how I see things here before too much support is garnered for Brunos style of confrontation. Okay.. that takes care of my vent for the next few months. :) I wish everyone on the D newsgroup many happy, joyous days. ;) -JJR
Jun 26 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 27 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jun 27 2006
next sibling parent John Reimer <terminal.node gmail.com> writes:
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
Jun 27 2006
prev sibling parent reply Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 30 2006
next sibling parent Sean Kelly <sean f4.ca> writes:
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
Jun 30 2006
prev sibling parent reply "Derek Parnell" <derek psych.ward> writes:
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
Jun 30 2006
parent "Derek Parnell" <derek psych.ward> writes:
On Sat, 01 Jul 2006 14:25:10 +1000, Derek Parnell <derek psych.ward> wrote:

Oops!
 I did and rewrote the docs for this.

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

-- Derek Parnell Melbourne, Australia
Jun 30 2006
prev sibling parent Bruno Medeiros <brunodomedeirosATgmail SPAM.com> writes:
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
Jun 30 2006
prev sibling parent reply Jari-Matti =?UTF-8?B?TcOka2Vsw6Q=?= <jmjmak utu.fi.invalid> writes:
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!

Yeah, as Bruno previously said, that should be allowed.
 2) you can override a public method and make it private ... ok, but get
 this -- the overload is not virtual -- it doesn't "actually" overload at
 all. Very sneaky bug in the making, especially when the base class is
 altered just slightly.
 
 3) to fix #2 let's use the override keyword! Yay! That will ensure we're
 actually overriding the base class method instance! Well, it compiles,
 but does *not* override. Bork Bork Bork.
 
 And so on, ad infinitum.

Damn, now all visibility / accessibility rules in D are totally broken. I really don't think the system is ever going to work the way it is documented now. The interface stuff and part of classes use the covariance rule in inheritance. It's also possible to contravariantly inherit a base class using class foo: private bar {} (a la C++). Then there are private attributes in classes and modules that don't work so well either. Hmmpf, hope someone has time to sort this out. We're counting on you, Walter :)
Jun 25 2006
parent reply Sean Kelly <sean f4.ca> writes:
Jari-Matti Mäkelä wrote:
 
 Damn, now all visibility / accessibility rules in D are totally broken.
 
 I really don't think the system is ever going to work the way it is
 documented now. The interface stuff and part of classes use the covariance
 rule in inheritance. It's also possible to contravariantly inherit a base
 class using class foo: private bar {} (a la C++). Then there are private
 attributes in classes and modules that don't work so well either. Hmmpf,
 hope someone has time to sort this out. We're counting on you, Walter :)

I think a careful programmer could make it work through extensive use of 'final'. However, it's obviously preferable to simply fix the bug :-) Sean
Jun 25 2006
parent reply =?ISO-8859-1?Q?Jari-Matti_M=E4kel=E4?= <jmjmak utu.fi.invalid> writes:
Sean Kelly wrote:
 Jari-Matti Mäkelä wrote:
 Damn, now all visibility / accessibility rules in D are totally broken.

 I really don't think the system is ever going to work the way it is
 documented now. The interface stuff and part of classes use the
 covariance
 rule in inheritance. It's also possible to contravariantly inherit a base
 class using class foo: private bar {} (a la C++). Then there are private
 attributes in classes and modules that don't work so well either. Hmmpf,
 hope someone has time to sort this out. We're counting on you, Walter :)

I think a careful programmer could make it work through extensive use of 'final'. However, it's obviously preferable to simply fix the bug :-)

True, a careful programmer doesn't need these protection mechanics at all. In fact we could write some l33t stuff in pure asm as well! But that's not my point. I really cannot believe there's only one bug preventing us from having a working compiler. There's not only some base classes and derived classes. They can also be nested in multiple levels and then there's modules & packages that need a consistent protection mechanics system with all classes. (then there's also templates and other possible stuff implementing protection) I don't get it - those all should be pretty consistent on a very high level. Now it seems like DMD has pretty ugly ad-hoc solutions for different situations. Then, to me it also seems to be totally braindead to mix both covariance and contravariance in inheritance semantics. Overriding in Java uses covariance (and that's the way it should work in D too, I think). Okay. Then there's public/protected/etc. inheritance from C++. Not only does it break possible elegant uses of interfaces a la Java, but it's also badly documented and implemented. In fact last time I checked it wasn't implemented at all. If it will be implemented some day, should we expect some kind of runtime exceptions when using these privately inherited classes covariantly? That works fine in C++ because C++ does not have interfaces, but IMO here it only adds confusion. Well, it might just be that I don't "get" it yet. Another problem related to these mechanics is that DMD is not able to handle the whole module hierarchy when judging the visibility / protection rules. A simple diamond shaped import hierarchy breaks the system. I wonder how it works with diamond shaped inner class hierarchies. -- Jari-Matti
Jun 25 2006
parent reply Dave <Dave_member pathlink.com> writes:
Jari-Matti Mäkelä wrote:
 Sean Kelly wrote:
 Jari-Matti Mäkelä wrote:
 Damn, now all visibility / accessibility rules in D are totally broken.

 I really don't think the system is ever going to work the way it is
 documented now. The interface stuff and part of classes use the
 covariance
 rule in inheritance. It's also possible to contravariantly inherit a base
 class using class foo: private bar {} (a la C++). Then there are private
 attributes in classes and modules that don't work so well either. Hmmpf,
 hope someone has time to sort this out. We're counting on you, Walter :)

'final'. However, it's obviously preferable to simply fix the bug :-)

True, a careful programmer doesn't need these protection mechanics at all. In fact we could write some l33t stuff in pure asm as well! But that's not my point. I really cannot believe there's only one bug preventing us from having a working compiler. There's not only some base classes and derived classes. They can also be nested in multiple levels and then there's modules & packages that need a consistent protection mechanics system with all classes. (then there's also templates and other possible stuff implementing protection) I don't get it - those all should be pretty consistent on a very high level. Now it seems like DMD has pretty ugly ad-hoc solutions for different situations. Then, to me it also seems to be totally braindead to mix both covariance and contravariance in inheritance semantics. Overriding in Java uses covariance (and that's the way it should work in D too, I think). Okay. Then there's public/protected/etc. inheritance from C++. Not only does it break possible elegant uses of interfaces a la Java, but it's also badly documented and implemented. In fact last time I checked it wasn't implemented at all. If it will be implemented some day, should we expect some kind of runtime exceptions when using these privately inherited classes covariantly? That works fine in C++ because C++ does not have interfaces, but IMO here it only adds confusion. Well, it might just be that I don't "get" it yet. Another problem related to these mechanics is that DMD is not able to handle the whole module hierarchy when judging the visibility / protection rules. A simple diamond shaped import hierarchy breaks the system. I wonder how it works with diamond shaped inner class hierarchies.

I think this can all be boiled down to 2 things: - Since D has chosen its OOP semantics to be based on those of Java, it should follow that model consistently w.r.t. co/contra-variance (after all it's seen pretty wide-spread use). - Even more importantly, make the darn protection attributes consistent between structs, classes, modules and packages no matter if parts of which are implemented with templates or not! - Dave
Jun 25 2006
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Dave wrote:

 Jari-Matti Mäkelä wrote:
 Sean Kelly wrote:
 Jari-Matti Mäkelä wrote:
 Damn, now all visibility / accessibility rules in D are totally broken.

 I really don't think the system is ever going to work the way it is
 documented now. The interface stuff and part of classes use the
 covariance
 rule in inheritance. It's also possible to contravariantly inherit a
 base class using class foo: private bar {} (a la C++). Then there are
 private attributes in classes and modules that don't work so well
 either. Hmmpf, hope someone has time to sort this out. We're counting
 on you, Walter :)

'final'. However, it's obviously preferable to simply fix the bug :-)

True, a careful programmer doesn't need these protection mechanics at all. In fact we could write some l33t stuff in pure asm as well! But that's not my point. I really cannot believe there's only one bug preventing us from having a working compiler. There's not only some base classes and derived classes. They can also be nested in multiple levels and then there's modules & packages that need a consistent protection mechanics system with all classes. (then there's also templates and other possible stuff implementing protection) I don't get it - those all should be pretty consistent on a very high level. Now it seems like DMD has pretty ugly ad-hoc solutions for different situations. Then, to me it also seems to be totally braindead to mix both covariance and contravariance in inheritance semantics. Overriding in Java uses covariance (and that's the way it should work in D too, I think). Okay. Then there's public/protected/etc. inheritance from C++. Not only does it break possible elegant uses of interfaces a la Java, but it's also badly documented and implemented. In fact last time I checked it wasn't implemented at all. If it will be implemented some day, should we expect some kind of runtime exceptions when using these privately inherited classes covariantly? That works fine in C++ because C++ does not have interfaces, but IMO here it only adds confusion. Well, it might just be that I don't "get" it yet. Another problem related to these mechanics is that DMD is not able to handle the whole module hierarchy when judging the visibility / protection rules. A simple diamond shaped import hierarchy breaks the system. I wonder how it works with diamond shaped inner class hierarchies.

I think this can all be boiled down to 2 things: - Since D has chosen its OOP semantics to be based on those of Java, it should follow that model consistently w.r.t. co/contra-variance (after all it's seen pretty wide-spread use). - Even more importantly, make the darn protection attributes consistent between structs, classes, modules and packages no matter if parts of which are implemented with templates or not! - Dave

Actually, Walter has stated in the past that if Java and C++ do something differently, he choose the C++ way. Now that almost nothing work in a way that anyone understand, I think it might be time to start over with OOP semantics that is best for D, no matter how it is done in C++, Java or C#. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Jun 25 2006
next sibling parent reply =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
Lars Ivar Igesund wrote:
 Actually, Walter has stated in the past that if Java and C++ do something
 differently, he choose the C++ way. Now that almost nothing work in a way
 that anyone understand, I think it might be time to start over with OOP
 semantics that is best for D, no matter how it is done in C++, Java or C#.

That would be the best way to go. The primary goal would be to obey the guidelines of language D and only after that some secondary goals like complexity of the implementation (compiler, not application programs). AFAIK the biggest problem with covariance is that derived classes reveal too much "internal" functionality to the rest of the world. C++ fixes this by hiding these members and Java does it by allowing access to classes through different interfaces. IMHO the way Java does it is overall much better since it does not generate runtime exceptions, when used correctly. The drawback is that since the whole implementation of the class is left open, it requires careful design when implementing individual class level components. Another option is to use has-a relationships where applicable. The way c++ does it is much more stricter. It really denies all illegal use, but needs to rely more on compile time checks. The problem here is that the reference compiler does not support this functionality (yet, I think). Another problem is that it might cause additional testing. Well, in principle it's possible to support both approaches at the same time, but I prefer the former approach myself. The only problem is that interfaces in D cannot be easily used as "roles" without much explicit casting. xs0 told in D.announce that it's possible to extend the functionality of interfaces without any extra overhead at all (but it would require more from the optimization logic of the compiler). Ok, this might be a bit OT, but still I think these all are a bit related. If Walter will do anything to "fix" these, I promise I will shut up, stop complaining and go write some useful programs. :) -- Jari-Matti
Jun 25 2006
parent reply xs0 <xs0 xs0.com> writes:
Just a slight correction :)

 xs0 told in D.announce that it's possible to extend the
 functionality of interfaces without any extra overhead at all (but it
 would require more from the optimization logic of the compiler).

It's possible to eliminate (time) overhead for calls on the same reference beyond the first (like in a loop or whatever). The first call of an interface method would still be about twice as expensive* as a "regular" virtual call (now it's just a few percent slower). On the other hand, there'd be no need for implicit casting on function boundaries that is happening now (currently, if you pass/return a class reference to a function expecting an interface reference, an implicit (runtime) cast happens, which would no longer be necessary). xs0 *) that's just the speed of the call sequence, obviously the function itself executes at "regular" speed, so the difference is not that large in practice
Jun 26 2006
parent =?UTF-8?B?SmFyaS1NYXR0aSBNw6RrZWzDpA==?= <jmjmak utu.fi.invalid> writes:
xs0 wrote:
 Just a slight correction :)
 
 xs0 told in D.announce that it's possible to extend the
 functionality of interfaces without any extra overhead at all (but it
 would require more from the optimization logic of the compiler).

It's possible to eliminate (time) overhead for calls on the same reference beyond the first (like in a loop or whatever). The first call of an interface method would still be about twice as expensive* as a "regular" virtual call (now it's just a few percent slower).

Right, forgot that. Sorry. I was already thinking about a situation where all this initialization could be done before the control jumps to the first line of the main(). But I guess that's not even possible because the classes can be dynamically allocated. But I think it should be obvious that this overhead is pretty minimal even without any optimizations at all. Traditionally a programmer would inline expensive function calls one way or another. But now it would not be necessary anymore. Better modularity, better software engineering. I still think it's a bit ridiculous to worry about an overhead of only a few opcodes - D is supposed to run on fast >= 32bit architectures, for god's sake. :)
Jun 26 2006
prev sibling parent Dave <Dave_member pathlink.com> writes:
Lars Ivar Igesund wrote:
 Dave wrote:
 

- Since D has chosen its OOP semantics to be based on those of Java, it should follow that model consistently w.r.t. co/contra-variance (after all it's seen pretty wide-spread use). - Even more importantly, make the darn protection attributes consistent between structs, classes, modules and packages no matter if parts of which are implemented with templates or not! - Dave

Actually, Walter has stated in the past that if Java and C++ do something differently, he choose the C++ way. Now that almost nothing work in a way

IMHO, that sounds like a good way to fall into the "corner case" trap - trying to merge C++ semantics w/ an OOP model more closely based on Java. I'd guess that probably the OP from Kris is a result of this (either way - if the rules were changed and/or the implementation is broken). I'd generally agree about the 'C++ default', but preferable to trying to please both camps, a common and readily implementable (working!) 'ground' must be found, even if Java programmers come out of this better than C++ programmers. If programmers and compiler writers are going to switch from C++ to D, I'd say for #1 above that what has been proved to work (and most easily implementable [Java]) is most important to get v1 out the door. For #2, consistency is just vital even if it is not the particular way that C++ programmers are used to. Otherwise D's going to scare off all of the OOP purists, OOP newbies and compiler implementors all in one shot.
 that anyone understand, I think it might be time to start over with OOP
 semantics that is best for D, no matter how it is done in C++, Java or C#.
 

Jun 25 2006