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?

"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.

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.

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

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