View mode: basic / threaded / horizontal-split · Log in · Help
August 05, 2005
A few pet peeves
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?
August 05, 2005
Re: A few pet peeves
"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.
August 05, 2005
Re: A few pet peeves
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.
August 06, 2005
Re: A few pet peeves
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?

# int freeFoo(int n) { return n; }
# class Bar { int function(int) foo = &freeFoo; }
# void main() { Bar bar = new Bar; bar.foo(); }

cheers
Mike
August 06, 2005
Re: A few pet peeves
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
Top | Discussion index | About this forum | D home