www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - A few pet peeves

reply BCS <BCS_member pathlink.com> writes:
I really like D, don’t get me wrong. It is far better than C/C++. I, as many
people have also noted, rarely find my self fighting the language to get things
done. But there’s one or two teensy little things that irritates the heck out of
me.

1)	The protection attributes STINK!! The public/private works well but what
about package and its ilk? Not only are they poorly defined as to what they do,
but about half the time I find my self having to look for walk around just to
get them to work.

2)	By example:

interface	I{foo();}
class A{void foo();}
class B:A{}	// B must not be able to overload foo
class C:A,I{}	// C must implement I using A.foo()

The most obvious way to do this is to make A.foo() final, but then you can’t
implement I in C. What has to be done is to derive a class D from A, and then
derive B from D

class D:A{final void foo(){super.foo();}}
class B:D…

Clumsy, clumsy, clumsy. One solution; allow classes to use alias function, e.g.
make A.foo() final and them in C do this:

class C:A{alias foo() super.foo();}

This would mean "define a function foo in C but use A.foo as the actual
function." This would also allow a class to implement an interface and use
parent class functions without having to write and use stubs.

BTW Why must a class that derives from an interface implement all of the
functions, even if a parent class already defines some of them?
Aug 05 2005
parent reply "Walter" <newshound digitalmars.com> writes:
"BCS" <BCS_member pathlink.com> wrote in message
news:dd0ksj$6re$1 digitaldaemon.com...

 BTW Why must a class that derives from an interface implement all of the
 functions, even if a parent class already defines some of them?


That goes back to "what does it mean to have the same interface more than
once in an inheritance heirarchy?" The idea is that for:

interface I;
class A : I;
class B : A, I;

the I in A.I is part of A, not part of the design of B. So if B derives from
I explicitly, then the implementor of B must be thinking to reimplement the
members of I. In other words, if class A no longer derived from I, then
class B shouldn't break.
Aug 05 2005
parent reply BCS <BCS_member pathlink.com> writes:
In article <dd0olc$9td$1 digitaldaemon.com>, Walter says...

"BCS" <BCS_member pathlink.com> wrote in message
news:dd0ksj$6re$1 digitaldaemon.com...

 BTW Why must a class that derives from an interface implement all of the
 functions, even if a parent class already defines some of them?


That goes back to "what does it mean to have the same interface more than
once in an inheritance heirarchy?" The idea is that for:

interface I;
class A : I;
class B : A, I;

the I in A.I is part of A, not part of the design of B. So if B derives from
I explicitly, then the implementor of B must be thinking to reimplement the
members of I. In other words, if class A no longer derived from I, then
class B shouldn't break.


Ah, I see. 

However this still leaves the (quite common I expect) issue of reusing an old
function in a new class. Another case where allowing function aliases IN A CLASS
would be nice is if you want to derive a class and use the old implementation of
a function but make it "final". This solution is no _worse_ than the alternative
(wrapper functions) because both will complain that the referenced function
doesn't exist if A is changed.
Aug 05 2005
next sibling parent Mike Capp <mike.capp gmail.com> writes:
In article <dd0u0k$dhb$1 digitaldaemon.com>, BCS says...

Another case where allowing function aliases IN A CLASS
would be nice 


Don't function pointers/delegates give you this ability?





cheers
Mike
Aug 06 2005
prev sibling parent Sean Kelly <sean f4.ca> writes:
In article <dd0u0k$dhb$1 digitaldaemon.com>, BCS says...

However this still leaves the (quite common I expect) issue of reusing an old
function in a new class. Another case where allowing function aliases IN A CLASS
would be nice is if you want to derive a class and use the old implementation of
a function but make it "final".


Agreed.  This would be nearly identical to how "using" is used in C++.


Sean
Aug 06 2005