aliasing base methods

[Lars Ivar Igesund]

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