www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - EndianStream needs to be reexamined!

reply Andreas Jung <webmaster aj-productions.de> writes:
*first post*

I've been switching from GDC to DMD 2.012 recently to check out the direction D
is heading into. Because I have worked with D1.0 code before, I am in
particular interested in porting D1.0 code to D2.0 code.

Regarding the CONST/string issue, I didn't find it too difficult to replace
"char[]" with "string". The original "char[]" was just more consistent and
intuitive when dealing with string manipulation. The question is whether this
new CONST/string thing justifies breaking tons of existing D codebase or not.

Back to my original concern. The new "function inheritance and overriding"
system is a pain in the a... . I have worked with object oriented languages

comprehensible polymorphism system which one was able to learn by looking at a
few examples.

Now look at the following example (which derives from my current problem while
trying to port existing code):

----------------------------------------------
import std.stream;

int main( char[][] args )
{
	// Create some specialized stream.
	auto es = new EndianStream( new TArrayStream!(string)( "test" ) );

	// Cast it to the type of its super class.
	Stream s = es;

	// Now call a member.
	char c;
	s.read( c ); // throws: HiddenFuncError

	// From the D specs:
	// " If an HiddenFuncError exception is thrown in your program,
	//   the use of overloads and overrides needs to be reexamined
	//   in the relevant classes."

	return 0;
}
----------------------------------------------

So is it a bug or a design feature?
If it's a design feature, I'll probably stop considering D2.0 an object
oriented language.

It cannot be true that such elementary OOP operations won't work any longer,
while they worked with D1.0. Even worse, these errors are not detected during
compile time, so hastily ported D1.0 code is lurking like a time bomb until
being invoked. This is not really acceptable. The D1.0 way was very intuitive
and simple (and it worked!), so why change it!?

So if I'm not missing the big point here, I think something is damn wrong with
the direction D is heading into. I think it would be a good idea to evolve the
D specs with backward compatibility in mind.

So, now I am here and I don't know whether to stay with D2.0 or go back to D1.0.
In D2.0, I'm stuck because I don't know how to get rid of the "HiddenFuncError"
exceptions inside my existing framework.
Going back to D1.0 however is just a short-term solution, because it WILL
become deprecated sooner or later, and I'd basically shirk from solving the
problems I have at the moment.

Andreas Jung
Mar 27 2008
parent reply "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Andreas Jung" wrote

 // Now call a member.
 char c;
 s.read( c ); // throws: HiddenFuncError

 // From the D specs:
 // " If an HiddenFuncError exception is thrown in your program,
 //   the use of overloads and overrides needs to be reexamined
 //   in the relevant classes."


This is exactly the issue I was talking about when I said that this is still 
a bad obscure bug.

http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56594

Walter, even you cannot keep track of where this bug will bite and have 
released phobos many times without noticing!  This example has been in 
phobos for a LONG time.  This bug was added in Phobos version 0.107.

Imagine if this were a mission-critical project and the bug wasn't seen 
until something really obscure happened to cause it.  These kinds of things 
will kill D as a choice for large-scale software development.

Can we please have this bug be a compile-time error?  (Walter, I wonder if 
you could run the exercise like you did for the class != null where you 
build a compiler that flags this as a failure and see how many errors are 
found?)

BTW, the issue is that EndianStream fails to inherit the parent's read for 
1-byte types (I'm guessing the reason was that there is no need to adjust 
byte order there), so read(byte), read(ubyte), and additionally write(char), 
write(byte), and write(ubyte) should fail.

To fix this, you need to put

alias Stream.read read;
alias Stream.write write;

into EndianStream.

-Steve
Mar 27 2008
parent reply Walter Bright <newshound1 digitalmars.com> writes:
Steven Schveighoffer wrote:

 Can we please have this bug be a compile-time error?  (Walter, I wonder if 
 you could run the exercise like you did for the class != null where you 
 build a compiler that flags this as a failure and see how many errors are 
 found?)


I think that's a good idea. I'll give it a try.
Mar 27 2008
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
"Walter Bright" wrote

 Steven Schveighoffer wrote:

 Can we please have this bug be a compile-time error?  (Walter, I wonder 
 if you could run the exercise like you did for the class != null where 
 you build a compiler that flags this as a failure and see how many errors 
 are found?)


 I think that's a good idea. I'll give it a try.


Any result on this?

-Steve
Apr 16 2008
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:

 Steven Schveighoffer wrote:

 Can we please have this bug be a compile-time error?  (Walter, I 
 wonder if you could run the exercise like you did for the class != 
 null where you build a compiler that flags this as a failure and see 
 how many errors are found?)


 
 I think that's a good idea. I'll give it a try.


Gotta say, told ya so.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 27 2008
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Can we please have this bug be a compile-time error?  (Walter, I 
 wonder if you could run the exercise like you did for the class != 
 null where you build a compiler that flags this as a failure and see 
 how many errors are found?)


 I think that's a good idea. I'll give it a try.


 
 Gotta say, told ya so.


Isn't this what the compiler warnings do ?

"warning - std/stream.d(2217): class std.stream.EndianStream Stream read 
is hidden in EndianStream"

--anders
Apr 27 2008
parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Can we please have this bug be a compile-time error?  (Walter, I 
 wonder if you could run the exercise like you did for the class != 
 null where you build a compiler that flags this as a failure and see 
 how many errors are found?)


 I think that's a good idea. I'll give it a try.


 Gotta say, told ya so.


 
 Isn't this what the compiler warnings do ?
 
 "warning - std/stream.d(2217): class std.stream.EndianStream Stream read 
 is hidden in EndianStream"
 
 --anders


Yes, it's what they do *now*. But when the feature was first introduced 
they threw a runtime error. I warned against it from the start:
"There is a problem the moment the D subclass doesn't override all
overloads, so that can be detected at compile time and an error issued
right there."
(http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=56419)



-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 27 2008
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Bruno Medeiros wrote:


 Gotta say, told ya so.


 Isn't this what the compiler warnings do ?

 "warning - std/stream.d(2217): class std.stream.EndianStream Stream 
 read is hidden in EndianStream"

 --anders


 
 Yes, it's what they do *now*.


Glad you were vindicated in the end. Too bad the error is still there,
the above warning is from compiling the Phobos in DMD 2.013 with -w...


 But when the feature was first introduced 
 they threw a runtime error. I warned against it from the start:
 "There is a problem the moment the D subclass doesn't override all
 overloads, so that can be detected at compile time and an error issued
 right there."
 (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars
D&article_id=56419) 


Yeah, Walter has a preference for "runtime warnings" such as exceptions.
And since warnings are optional, you can still miss them apparently...

--anders
Apr 27 2008
parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Anders F Björklund wrote:

 Bruno Medeiros wrote:
 

 Gotta say, told ya so.


 Isn't this what the compiler warnings do ?

 "warning - std/stream.d(2217): class std.stream.EndianStream Stream 
 read is hidden in EndianStream"

 --anders


 Yes, it's what they do *now*.


 
 Glad you were vindicated in the end. Too bad the error is still there,
 the above warning is from compiling the Phobos in DMD 2.013 with -w...
 

 But when the feature was first introduced they threw a runtime error. 
 I warned against it from the start:
 "There is a problem the moment the D subclass doesn't override all
 overloads, so that can be detected at compile time and an error issued
 right there."
 (http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars
D&article_id=56419) 


 
 
 Yeah, Walter has a preference for "runtime warnings" such as exceptions.
 And since warnings are optional, you can still miss them apparently...
 
 --anders


Hum, another distraction of mine, I read the changelog and thought an 
error had been added, not a warning. I'm not sure which of the two I prefer.

-- 
Bruno Medeiros - Software Developer, MSc. in CS/E graduate
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Apr 29 2008