For the following code in D 2.0 using dmd 2.049:

import std.stdio;

abstract class foo {
protected:
	void WrongType(){
		assert(0,"Using wrong type");
	}
public:
	void Update(int value){WrongType();}
 	void Update(float value){WrongType();}
}

class blup : public foo {
	public override void Update(int value){
		writefln("%s",value);
	}
}

void main(string[] argv){
	foo s = new blup();
	s.Update(2);
	s.Update(2.5f);
}

When compiling with -w option I get the following warning:
test.d(25): Error: class test.blup test.foo.Update(float value) is hidden by blup

When compiling without the -w option I get the following runtime error: core.exception.HiddenFuncError: Hidden method called for test.blup

So I don't get why void Update(float value) is hidden. I come from C++ so
please show me my mistake.

Kind Regards
Benjamin Thaut

On Thu, 07 Oct 2010 10:43:12 +0400, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> For the following code in D 2.0 using dmd 2.049:
>
> import std.stdio;
>
> abstract class foo {
> protected:
> 	void WrongType(){
> 		assert(0,"Using wrong type");
> 	}
> public:
> 	void Update(int value){WrongType();}
>  	void Update(float value){WrongType();}
> }
>
> class blup : public foo {
> 	public override void Update(int value){
> 		writefln("%s",value);
> 	}
> }
>
> void main(string[] argv){
> 	foo s = new blup();
> 	s.Update(2);
> 	s.Update(2.5f);
> }
>
> When compiling with -w option I get the following warning:
> test.d(25): Error: class test.blup test.foo.Update(float value) is hidden by blup
>
> When compiling without the -w option I get the following runtime error:
> core.exception.HiddenFuncError: Hidden method called for test.blup
>
> So I don't get why void Update(float value) is hidden. I come from C++ so
> please show me my mistake.
>
> Kind Regards
> Benjamin Thaut

That the case in C++, too. In C++ you would write using foo::Update.
In D, "alias foo.Update Update". It means, "bring base class' Update method to the current scope".

Thanks, that fixes it

Kind Regards
Benjamin Thaut

Benjamin Thaut:

> abstract class foo {
> protected:
> 	void WrongType(){
> 		assert(0,"Using wrong type");
> 	}

In D classes start with an upper case, and methods with a lower case (and both generally use camelCase/CamelCase instead of underscores).

So the way to write that code is:

abstract class Foo {
  protected:
    void wrongType() {

Bye,
bearophile

bearophile <bearophileHUGS@lycos.com> wrote:
> In D classes start with an upper case, and methods with a lower case (and both generally use camelCase/CamelCase instead of underscores).
>
> So the way to write that code is:
>
> abstract class Foo {
>   protected:
>     void wrongType() {

Yes, if one is to slavishly follow the rules set out by someone else.
People may have other coding standards in their own homes.

-- 
Simen

Simen kjaeraas:

> Yes, if one is to slavishly follow the rules set out by someone else. People may have other coding standards in their own homes.

How many serious Python packages do you see around where methods are named in CamelCase? How many serious C# libraries do you see around written with lowercase methods, or lowercase class names?

The D language doesn't enforce identifiers case conventions, and in the end you are free to do what you like. But you have to push your nose a bit outside your box, when you program in Python, C#, D and so on your "home" is the community.

It's good to have basic language-wide style used by the whole community, it simplifies code written by others. Think about using CamelCase in your Python project. Then you download modules from all places from the net, and add them to your Python program (this happens often in Python).

If one module uses names_with_underscores, another module uses camelCase, and another module uses alllowercasewithnospaces then at the end your project will look like more like an Harlequin, harder to read, confusing. But Python/C# devs are not that stupid, they follow things like the Python PEP8, that says to use class names with an Upper case starting char, methods as lower_case, and so on.

Freedom is good, but in this case its price is too much high, it's not worth it. Stick with the naming convention used by each modern language, you will have less problems in integrating code written by other people, and your code will turn up to be better and more readable by the community.

Bye,
bearophile