Much to his credit, Walter has often noted specific reasoning for the presence or absence of some particular D language-choice. Perhaps someone will please be good enough to clarify one that (superficially) doesn't seem to have received much attention:  according to the spec, "All interface functions must be defined in a class that inherits from that interface". The compiler says so also.

I have several issues with this, but to put it in a nutshell: *partial implementation (via an abstract class) can be, and in larger projects is often used as, a gracious mechanism for solving real-world problems*

<rant>
Ok. Certainly one can work around this by implementing fake members in said
"abstract" base-class, and throw an exception in each of those that should
*actually* be implemented by a subclass ... but that is serious kludge,
especially since instantiation of said abstract class would be perfectly
legal at *compile-time*. That's not cool. It's also far less than helpful to
a smart IDE that could guide a user in what they should truly be
implementing. Should such an IDE resort to "hints" in the (non-existent)
documentation? These kind of things are important vis-a-vis acceptance.

Here's something else: what D needs to gain wide acceptance is good set of
libraries. The easiest way to get those quickly is to port existing
proven/accepted/cool/elegant ones. One particular type of D library that
seems rather popular is that of the GUI manager/widget library. How many of
those are there? Hmmmm, four or more current projects? Far more popular than
any other type of library, because it's a necessity for a large swathe of
software development. The SWT port is such a project, and it truly has the
potential to make D shine. How easy do you think it's gonna' be for those
poor folks to (mechanically) port SWT over to D without support for
partial-implementation and/or abstract-classes?
</rant>

Porting great libraries is a *truly* real-world problem -- if we can make that easier then D has a better chance of acceptance in such an environment.

So, finally, why doesn't D support partial-implementation/abstract-classes? I'm sure there's probably a good reason why it's not already there; but what is that reason?

- Kris

Kris wrote:
> Much to his credit, Walter has often noted specific reasoning for the
> presence or absence of some particular D language-choice. Perhaps someone
> will please be good enough to clarify one that (superficially) doesn't seem
> to have received much attention:  according to the spec, "All interface
> functions must be defined in a class that inherits from that interface". The
> compiler says so also.
> 
> I have several issues with this, but to put it in a nutshell: *partial
> implementation (via an abstract class) can be, and in larger projects is
> often used as, a gracious mechanism for solving real-world problems*

Abstract classes work great in D.  The problem is that you can't implement part of an interface with one.  I'm about as happy with it as you are. :)

 -- andy

> Here's something else: what D needs to gain wide acceptance is good set of
> libraries. The easiest way to get those quickly is to port existing
> proven/accepted/cool/elegant ones. One particular type of D library that
> seems rather popular is that of the GUI manager/widget library. How many of
> those are there? Hmmmm, four or more current projects? Far more popular than
> any other type of library, because it's a necessity for a large swathe of
> software development. The SWT port is such a project, and it truly has the
> potential to make D shine. How easy do you think it's gonna' be for those
> poor folks to (mechanically) port SWT over to D without support for
> partial-implementation and/or abstract-classes?
And Java's collections.
Sam

Kris wrote:
> Much to his credit, Walter has often noted specific reasoning for the
> presence or absence of some particular D language-choice. Perhaps someone
> will please be good enough to clarify one that (superficially) doesn't seem
> to have received much attention:  according to the spec, "All interface
> functions must be defined in a class that inherits from that interface". The
> compiler says so also.
> 
> I have several issues with this, but to put it in a nutshell: *partial
> implementation (via an abstract class) can be, and in larger projects is
> often used as, a gracious mechanism for solving real-world problems*
> 
> <rant>
> Ok. Certainly one can work around this by implementing fake members in said
> "abstract" base-class, and throw an exception in each of those that should
> *actually* be implemented by a subclass ... but that is serious kludge,
> especially since instantiation of said abstract class would be perfectly
> legal at *compile-time*. That's not cool. It's also far less than helpful to
> a smart IDE that could guide a user in what they should truly be
> implementing. Should such an IDE resort to "hints" in the (non-existent)
> documentation? These kind of things are important vis-a-vis acceptance.
> 
> Here's something else: what D needs to gain wide acceptance is good set of
> libraries. The easiest way to get those quickly is to port existing
> proven/accepted/cool/elegant ones. One particular type of D library that
> seems rather popular is that of the GUI manager/widget library. How many of
> those are there? Hmmmm, four or more current projects? Far more popular than
> any other type of library, because it's a necessity for a large swathe of
> software development. The SWT port is such a project, and it truly has the
> potential to make D shine. How easy do you think it's gonna' be for those
> poor folks to (mechanically) port SWT over to D without support for
> partial-implementation and/or abstract-classes?
> </rant>
> 
> Porting great libraries is a *truly* real-world problem -- if we can make
> that easier then D has a better chance of acceptance in such an environment.
> 
> So, finally, why doesn't D support partial-implementation/abstract-classes?
> I'm sure there's probably a good reason why it's not already there; but what
> is that reason?

I agree. It makes interfaces very hard to use, since you cannot write implementation helpers without "hacking" (i.e. providing dummy implementations and trusting on the implementing class to overload them). I already posted about this a while back.

A related issue is the following: A class has inherited an implementation of an interface X from its base class and then implements an interface Y which is derived from X. Then all functions in X have to be implemented again. This makes it very messy to create a hierarchy of interfaces and then provide a hierarchy of classes as an implementation for them. Because as interfaces grow bigger you have to litter your classes with dummy-functions that simply call the base class implementation. That is tiresome and makes code very hard to read, because you have to wade through all those dummies to find the points in the code where some real implementation is provided.

C++ has the same problem, but at least there you can write a macro that adds all these dummy calls for a particular interface. In D that isn't possible, so you end up manually copying dozens of dummy functions into each and every class you write.

Interfaces in D just aren't supported well (yet?). If you try to really use them to abstract from the specific implementations you end up in a world of dirty hacks.

If I extrapolate from all my other experiences with what I'd call flaws in D, then my guess is that Walter doesn't use interfaces ;).

Hauke

Interfaces are good for contracts, take a look at that plugin system i attached to the post "Mathew, here, more detailed".

On Sun, 22 Feb 2004 00:36:14 -0800, Kris <someidiot@earthlink.net> wrote:

> Much to his credit, Walter has often noted specific reasoning for the
> presence or absence of some particular D language-choice. Perhaps someone
> will please be good enough to clarify one that (superficially) doesn't seem
> to have received much attention:  according to the spec, "All interface
> functions must be defined in a class that inherits from that interface". The
> compiler says so also.
>
> I have several issues with this, but to put it in a nutshell: *partial
> implementation (via an abstract class) can be, and in larger projects is
> often used as, a gracious mechanism for solving real-world problems*
>
> <rant>
> Ok. Certainly one can work around this by implementing fake members in said
> "abstract" base-class, and throw an exception in each of those that should
> *actually* be implemented by a subclass ... but that is serious kludge,
> especially since instantiation of said abstract class would be perfectly
> legal at *compile-time*. That's not cool. It's also far less than helpful to
> a smart IDE that could guide a user in what they should truly be
> implementing. Should such an IDE resort to "hints" in the (non-existent)
> documentation? These kind of things are important vis-a-vis acceptance.
>
> Here's something else: what D needs to gain wide acceptance is good set of
> libraries. The easiest way to get those quickly is to port existing
> proven/accepted/cool/elegant ones. One particular type of D library that
> seems rather popular is that of the GUI manager/widget library. How many of
> those are there? Hmmmm, four or more current projects? Far more popular than
> any other type of library, because it's a necessity for a large swathe of
> software development. The SWT port is such a project, and it truly has the
> potential to make D shine. How easy do you think it's gonna' be for those
> poor folks to (mechanically) port SWT over to D without support for
> partial-implementation and/or abstract-classes?
> </rant>
>
> Porting great libraries is a *truly* real-world problem -- if we can make
> that easier then D has a better chance of acceptance in such an environment.
>
> So, finally, why doesn't D support partial-implementation/abstract-classes?
> I'm sure there's probably a good reason why it's not already there; but what
> is that reason?
>
> - Kris
>
>
>
>



-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

"Kris" <someidiot@earthlink.net> wrote in message
news:c19p93$21f7$1@digitaldaemon.com...
| Much to his credit, Walter has often noted specific reasoning for the
| presence or absence of some particular D language-choice. Perhaps someone
| will please be good enough to clarify one that (superficially) doesn't seem
| to have received much attention:  according to the spec, "All interface
| functions must be defined in a class that inherits from that interface". The
| compiler says so also.
|
| I have several issues with this, but to put it in a nutshell: *partial
| implementation (via an abstract class) can be, and in larger projects is
| often used as, a gracious mechanism for solving real-world problems*

It does seem unfortunate that you can't do:

 interface A
 {
   void foo();
   void bar();
 }
 class B:A // partial implementation
 {
   void foo() {}
   abstract void bar(); // complains that bar needs a body
 }
 class C:B
 {
   void bar() {}
 }

| <rant>
| Ok. Certainly one can work around this by implementing fake members in said
| "abstract" base-class, and throw an exception in each of those that should
| *actually* be implemented by a subclass ... but that is serious kludge,
| especially since instantiation of said abstract class would be perfectly
| legal at *compile-time*. That's not cool. It's also far less than helpful to
| a smart IDE that could guide a user in what they should truly be
| implementing. Should such an IDE resort to "hints" in the (non-existent)
| documentation? These kind of things are important vis-a-vis acceptance.
|
| Here's something else: what D needs to gain wide acceptance is good set of
| libraries. The easiest way to get those quickly is to port existing
| proven/accepted/cool/elegant ones. One particular type of D library that
| seems rather popular is that of the GUI manager/widget library. How many of
| those are there? Hmmmm, four or more current projects? Far more popular than
| any other type of library, because it's a necessity for a large swathe of
| software development. The SWT port is such a project, and it truly has the
| potential to make D shine. How easy do you think it's gonna' be for those
| poor folks to (mechanically) port SWT over to D without support for
| partial-implementation and/or abstract-classes?

What in SWT needs partially implemented interfaces? I'm not an SWT programmer
so I'm honestly asking. Glancing at the javadoc it looks like some classes
are marked abstract so that users don't instantiate them. Plus the Widget
class has an abstract getDisplay() but that isn't implementing any interface.
I must be missing something because this doesn't seem like a problem for a
D port. Just declare the getDisplay method as abstract. I just tried declaring
the whole class as abstract and that didn't seem to prevent me from
instantiating it, so that seems like a bug. But I don't think that is what
you are concerned about.

| </rant>
|
| Porting great libraries is a *truly* real-world problem -- if we can make
| that easier then D has a better chance of acceptance in such an environment.
|
| So, finally, why doesn't D support partial-implementation/abstract-classes?
| I'm sure there's probably a good reason why it's not already there; but what
| is that reason?

My personal experience from Java is that single inheritance makes abstract classes less useful since it forces users to subclass from *only* your class instead of allowing them to subclass something else. I've found abstract classes are usually done to provide helper routines around some interface. There have been earlier threads about "mixins" that are relevant and I seem to recall Walter saying he's thinking about it.

|
| - Kris
|
|
|
|

In article <c19p93$21f7$1@digitaldaemon.com>, Kris says...
>
>Much to his credit, Walter has often noted specific reasoning for the presence or absence of some particular D language-choice. Perhaps someone will please be good enough to clarify one that (superficially) doesn't seem to have received much attention:  according to the spec, "All interface functions must be defined in a class that inherits from that interface". The compiler says so also.
>
>I have several issues with this, but to put it in a nutshell: *partial implementation (via an abstract class) can be, and in larger projects is often used as, a gracious mechanism for solving real-world problems*

- The concept of abstract class is crippled (at least how I'm use to them)
- concret classes will forget to reimplement empty, dummy methods.
- IDEs will have more trouble to create the outline of class from a
super abstract class.
- (more for sure)

This is a real problem for OO D - not a detail.

Walter, don't let us arguing for weeks please say something.

Ant

John Reimer and I *are* those poor folks, and it's becoming a problem.  I still don't know a work-around to get the compiler to stop complaining.  Should we change the abstracts and interfaces to plain old classes, inherit the "partial-implementation" and be disciplined about which members we implement? Or should we try your throwing exceptions idea?

BA


Kris wrote:
> The SWT port is such a project, and it truly has the
> potential to make D shine. How easy do you think it's gonna' be for those
> poor folks to (mechanically) port SWT over to D without support for
> partial-implementation and/or abstract-classes?

In article <c1aobj$m94$1@digitaldaemon.com>, Brad Anderson says...
>
>John Reimer and I *are* those poor folks, and it's becoming a problem.  I still don't know a work-around to get the compiler to stop complaining.  Should we change the abstracts and interfaces to plain old classes, inherit the "partial-implementation" and be disciplined about which members we implement? Or should we try your throwing exceptions idea?
>
>BA

neither.

You should convince Walter that abstract classes
don't need a full implementation of the interface.

Ant

Brad Anderson wrote:

> John Reimer and I *are* those poor folks, and it's becoming a problem.  I still don't know a work-around to get the compiler to stop complaining.  Should we change the abstracts and interfaces to plain old classes, inherit the "partial-implementation" and be disciplined about which members we implement? Or should we try your throwing exceptions idea?

I'd throw an InternalError or somesuch until we can get Walter to cave in and fix it. (or at least tell us why it can't/shouldn't be fixed)

 -- andy