*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 such as C++/Jave/C#/managed C++/C++ CLI etc., and all of them had a 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

"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

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.

"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

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

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

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

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

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