View mode: basic / threaded / horizontal-split · Log in · Help
February 25, 2007
aliasing base methods
Why do we really need this strange overloading, reimplementation rules.
It is so annoying.

If you overload a method from a base class you hide the base method. To
avoid this you need to do an alias.
alias Base.fnc fnc;

If more than one version of fnc exists, you cannot specify which one
shall be alias.

There is no advantage in this. Without this rule, you can probably
overload instead of the intended override (But we already have the
override keyword, make it required?). With this rule, you probably hide
an existing base implementation and probably change the behaviour of the
class, if the overloaded function is compatible to the base version.
(e.g. visitor pattern).

Another pain point: Why do we really need to reimplement a method if an
interface is again used?
interface I{ void fnc(); }
class B : I { void fnc(){} }
class C : B, I { } // error needs to reimplement fnc.
February 25, 2007
Re: aliasing base methods
Frank Benoit (keinfarbton) wrote:
> Why do we really need this strange overloading, reimplementation rules.
> It is so annoying.
>
> If you overload a method from a base class you hide the base method. To
> avoid this you need to do an alias.
> alias Base.fnc fnc;

It can be a bit annoying at times, yes.

> If more than one version of fnc exists, you cannot specify which one
> shall be alias.

If you aliased an overloaded function or method name, you alias *all* 
the overloaded versions:
---
urxae@urxae:~/tmp$ cat test.d
import std.stdio;

class Base {
    void foo(int) { writefln("foo(int)"); }
    void foo(char[]) { writefln("foo(char[])"); }
}

class Derived : Base {
    void foo(float) { writefln("foo(float)"); }
    alias Base.foo foo;
}

void main(){
    Derived d = new Derived;
    d.foo(1);
    d.foo("bar");
    d.foo(1.0);
}
urxae@urxae:~/tmp$ dmd -run test.d
foo(int)
foo(char[])
foo(float)
---

Judging by your views on the rest of this matter, I think you will agree 
that this is usually what you want to do.

However, this seems to be another manifestation of the inability to 
specify specific overloads that is also so annoying when trying to take 
a function pointer (or in this case delegate) of an overloaded 
function/method.
A syntax for this has been proposed (e.g. &d.foo(int)) but I don't 
recall Walter responding to it. (If he did, it probably wasn't 
positively or I would have remembered)

> There is no advantage in this. Without this rule, you can probably
> overload instead of the intended override (But we already have the
> override keyword, make it required?). With this rule, you probably hide
> an existing base implementation and probably change the behaviour of the
> class, if the overloaded function is compatible to the base version.
> (e.g. visitor pattern).


> Another pain point: Why do we really need to reimplement a method if an
> interface is again used?
> interface I{ void fnc(); }
> class B : I { void fnc(){} }
> class C : B, I { } // error needs to reimplement fnc.

I can understand this one, actually. The way I see it, the only reason 
to reimplement an interface is to make sure it remains implemented even 
if the base class is modified. So the only way to keep it compiling if 
the interface is removed from the base class is to ensure you provide 
implementations.
On the other hand, an argument could be made that compile-time errors 
("interface method not implemented: 'I.fnc'") would be appropriate in 
this case...
February 25, 2007
Re: aliasing base methods
My point is, i want this strange rules to be removed.
And I want the override keyword not to be a useless thing.

I propose:
1.) make an overload not hide base implementations
2.) make the override keyword required, to make it useful.
3.) remove the interface reimplementation rule.

What do you think?
February 25, 2007
Re: aliasing base methods
Frank Benoit (keinfarbton) wrote:

> 
> My point is, i want this strange rules to be removed.
> And I want the override keyword not to be a useless thing.
> 
> I propose:
> 1.) make an overload not hide base implementations

votes++

> 2.) make the override keyword required, to make it useful.

Not so sure about this one. It will introduce a lot of unnecessary typing
and that can be annoying if you want the function prototypes to fit into 80
characters. 

> 3.) remove the interface reimplementation rule.

Definitely a good idea.

> 
> What do you think?
February 25, 2007
Re: aliasing base methods
>> 2.) make the override keyword required, to make it useful.
> 
> Not so sure about this one. It will introduce a lot of unnecessary typing
> and that can be annoying if you want the function prototypes to fit into 80
> characters. 

I think in any bigger software, the keyword override should be used
consequently. It makes sure that a typo doesn't makes an overload
instead of an override and vice versa. Which is a bug, very hard to find.

But actually this works only in one direction (1) and it cannot be enforced.

(1) Only in one direction means, you can make sure your override is an
override, but you cannot make sure your overload is an overload. If
"override" would be required, this check works in both directions. (no
"override" means, its a not an override)

Another advantage is, in big programs, classes with many methods. You
can be sure that a overridden method is marked as such. That make
understanding of code easier.

I think every good editor can assist here very good and I believe, the
benefit of an explicit "override" is higher than the cost of
typing/autocompleting it.
February 25, 2007
Re: aliasing base methods
Frank Benoit (keinfarbton) wrote:

> 
> My point is, i want this strange rules to be removed.
> And I want the override keyword not to be a useless thing.
> 
> I propose:
> 1.) make an overload not hide base implementations
> 2.) make the override keyword required, to make it useful.
> 3.) remove the interface reimplementation rule.
> 
> What do you think?

I agree strongly with all 3 above. And 2) will be a unique help for any
program that are to be mantained for any amount of time. It is nothing but
an extension to the already existing contracts. Mantainable programs are
another area where D can shine, but then we need to take opportunities like
this.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
February 25, 2007
Re: aliasing base methods
Frank Benoit (keinfarbton) wrote:

> 
>>> 2.) make the override keyword required, to make it useful.
>> 
>> Not so sure about this one. It will introduce a lot of unnecessary typing
>> and that can be annoying if you want the function prototypes to fit into
>> 80 characters.
> 
> I think in any bigger software, the keyword override should be used
> consequently. It makes sure that a typo doesn't makes an overload
> instead of an override and vice versa. Which is a bug, very hard to find.
> 
> But actually this works only in one direction (1) and it cannot be
> enforced.
> 
> (1) Only in one direction means, you can make sure your override is an
> override, but you cannot make sure your overload is an overload. If
> "override" would be required, this check works in both directions. (no
> "override" means, its a not an override)
> 
> Another advantage is, in big programs, classes with many methods. You
> can be sure that a overridden method is marked as such. That make
> understanding of code easier.
> 
> I think every good editor can assist here very good and I believe, the
> benefit of an explicit "override" is higher than the cost of
> typing/autocompleting it.

I'm more concerned about redability when the lines get to long than typing.
And I also don't think that enforcement of overload/override is that
important, no other language I have used does this and if a class have so
many methods that they cant be kept track of is probably missdesigned.
February 25, 2007
Re: aliasing base methods
Johan Granberg wrote:

> Frank Benoit (keinfarbton) wrote:
> 
>> 
>>>> 2.) make the override keyword required, to make it useful.
>>> 
>>> Not so sure about this one. It will introduce a lot of unnecessary
>>> typing and that can be annoying if you want the function prototypes to
>>> fit into 80 characters.
>> 
>> I think in any bigger software, the keyword override should be used
>> consequently. It makes sure that a typo doesn't makes an overload
>> instead of an override and vice versa. Which is a bug, very hard to find.
>> 
>> But actually this works only in one direction (1) and it cannot be
>> enforced.
>> 
>> (1) Only in one direction means, you can make sure your override is an
>> override, but you cannot make sure your overload is an overload. If
>> "override" would be required, this check works in both directions. (no
>> "override" means, its a not an override)
>> 
>> Another advantage is, in big programs, classes with many methods. You
>> can be sure that a overridden method is marked as such. That make
>> understanding of code easier.
>> 
>> I think every good editor can assist here very good and I believe, the
>> benefit of an explicit "override" is higher than the cost of
>> typing/autocompleting it.
> 
> I'm more concerned about redability when the lines get to long than
> typing. And I also don't think that enforcement of overload/override is
> that important, no other language I have used does this and if a class
> have so many methods that they cant be kept track of is probably
> missdesigned.

That no other language you've used has it is hardly a good reason. It isn't
to keep track of said methods, but to bind them to a contract that can be
enforced like interfaces, DbC and unittests.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
February 25, 2007
Re: aliasing base methods
Johan Granberg wrote:
> Frank Benoit (keinfarbton) wrote:
> 

> I'm more concerned about redability when the lines get to long than typing.

public override
int some_method_with_a_long_name(and with, lots of, parameters too);

??

> And I also don't think that enforcement of overload/override is that
> important, no other language I have used does this and if a class have so
> many methods that they cant be kept track of is probably missdesigned. 

I don't think it's so much a matter of having too many methods to keep 
track of, but just not realizing there's a method there you're 
shadowing, or accidentally getting the argument types slightly wrong.

--bb
February 25, 2007
Re: aliasing base methods
Lars Ivar Igesund wrote:
> Frank Benoit (keinfarbton) wrote:
> 
>> My point is, i want this strange rules to be removed.
>> And I want the override keyword not to be a useless thing.
>>
>> I propose:
>> 1.) make an overload not hide base implementations

What does this mean when combined with number 2?

class Base
{
   int foo(int) { ... }
}
class Derived : Base
{
   // Is this "error: override keyword required"
   // Or is it ok -- not an override but a distict overload leaving
   // foo(int) in tact.
   int foo(float) { ... }
}

If the above code requires 'override' then the meaning of 'override' is 
getting stretched too far.  I that case it isn't overriding anything.

If the above code is OK as is, then that's also a problem because one of 
the most common bugs with overriding is getting the signature wrong.  I 
guess if override is required for actual overriding that means the above 
coder was actually making two mistakes -- forgetting to say 'override' 
*and* getting the signature wrong, but I don't think that combination of 
mistakes would be terribly uncommon.

In short, the above code looks like it's probably a coder error and the 
coder meant to override foo(int).  But you can't be sure.

>> 2.) make the override keyword required, to make it useful.

+1

But note above about not playing nice with exposed base implementations. 
 If overloaded base implementations were not automatically inherited 
then the above would actually give a useful error because foo(float) is 
hiding (and thereby overriding) foo(int), though it is not declared 
'override'.

>> 3.) remove the interface reimplementation rule.

That sounds ok to me -- actually my naive expectation was that that was 
how interfaces already worked.

--bb
« First   ‹ Prev
1 2 3
Top | Discussion index | About this forum | D home