EndianStream needs to be reexamined!

[Andreas Jung]

*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