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.


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.
 

 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.


 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.


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 

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.


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



override, and because " Private members cannot be overridden" 
(http://www.digitalmars.com/d/attribute.html).




 
 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

 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 

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!






 

 

 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 


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









 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 


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 

 
 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 

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


behavior, and I regret that my "student" argument was not enough by 

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 

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 

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


 behavior, and I regret that my "student" argument was not enough by 

 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 

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


 broken behavior, and I regret that my "student" argument was not 

 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 

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


 broken behavior, and I regret that my "student" argument was not 

 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 

 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.
 

 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 :)


 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.
 


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 :)


 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.
 


 
 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


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



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:
 


 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


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, 


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

 





 Jun 25 2006