www.digitalmars.com         C & C++   DMDScript  

D - Partial implementation of Interfaces (Walter?)

reply "Kris" <someidiot earthlink.net> writes:
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
Feb 22 2004
next sibling parent Andy Friesen <andy ikagames.com> writes:
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
Feb 22 2004
prev sibling next sibling parent Sam McCall <tunah.d tunah.net> writes:
 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
Feb 22 2004
prev sibling next sibling parent Hauke Duden <H.NS.Duden gmx.net> writes:
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
Feb 22 2004
prev sibling next sibling parent SpookyET <not4_u hotmail.com> writes:
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/
Feb 22 2004
prev sibling next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"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
|
|
|
|
Feb 22 2004
prev sibling next sibling parent Ant <Ant_member pathlink.com> writes:
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
Feb 22 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
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?
Feb 22 2004
next sibling parent reply Ant <Ant_member pathlink.com> writes:
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
Feb 22 2004
parent Ant <Ant_member pathlink.com> writes:
In article <c1aqle$q79$1 digitaldaemon.com>, Ant says...
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
BTW do you remember I warned about this problem a couple of months ago when we started talking about SWT? (couldn't find the post) I didn't realize it is by design and not a bug... Ant
Feb 22 2004
prev sibling parent reply Andy Friesen <andy ikagames.com> writes:
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
Feb 22 2004
parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Andy Friesen" <andy ikagames.com> wrote in message
news:c1ar58$qvs$1 digitaldaemon.com...
 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)
I guess you've no choice. But having runtime error checks for something that is pre-compile-time, i.e. design time, is just evil.
Feb 22 2004
prev sibling next sibling parent reply Sean Kelly <sean ffwd.cx> writes:
Kris wrote:
 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*
Perhaps I'm missing something, but is there some reason the interfaces can't be broken up? Here's an example: class CanRunAndJump -> class CanRun -> interface JumperRunner From what you've said, this may be a case where I'd like to implement the running methods in CanRun and leave the jumping methods for the CanRunAndJump class. Is this right? If so, I don't agree that partial implementation is a good thing. It would make more logical sense to do this: class CanRunAndJump -> class CanRun -> interface RunnerAndJumper class CanRunAndJump -> interface Jumper Or is the goal to provide paritally implemented base classes and force the user to implement the remaining methods? In this case, why not do this: interface RunnerAndJumper { void run(); void jump(); } class CanRun : RunnerAndJumper { void run() {} void jump() in { assert( 0 ); // this function must be overridden in a base class } {} }
Feb 22 2004
next sibling parent reply "Kris" <someidiot earthlink.net> writes:
Inline:


"Sean Kelly" <sean ffwd.cx> wrote in message
news:c1b8jd$1ipi$1 digitaldaemon.com...
  From what you've said, this may be a case where I'd like to implement
 the running methods in CanRun and leave the jumping methods for the
 CanRunAndJump class.  Is this right?  If so, I don't agree that partial
 implementation is a good thing.  It would make more logical sense to do
 this:

 class CanRunAndJump -> class CanRun -> interface RunnerAndJumper
 class CanRunAndJump -> interface Jumper
Did you mean "interface Runner" (not "interface RunnerAndJumper") in the first line? If so I agree, but that example is not the issue.
 Or is the goal to provide paritally implemented base classes and force
 the user to implement the remaining methods?  In this case, why not do
this:
 interface RunnerAndJumper {
      void run();
      void jump();
 }

 class CanRun : RunnerAndJumper {
      void run() {}
      void jump()
      in {
          assert( 0 );
          // this function must be overridden in a base class
      }
      {}
 }
It's this second example that I have a beef with Sean; (1) we perhaps ought to change it as follows because it should *always* fail (this is what I shivered at in the initial post).: class CanRun : RunnerAndJumper { void run() {} void jump() { // this function must be overridden in a base class assert( 0 ); } } (2) how does an IDE tell the programmer what specifically should be overridden? It can't. And you can't rely on access to the source code for such classes, although you should have the public interface (but that still tells you squat). More importantly, there should be a compile-time error (versus runtime) about instantiation or usage of such an implementation. This is simply a ticking bomb -- not cool at all. (3) such 'declarative' interfaces are great for plugable systems, where multiple people or vendors are involved. For example, you might expose a specific kind of device-driver via such an interface, but the concrete implementations built by each hardware vendor would at minimum implement only their specialized variation [jump(), in this case] whereas run() could be common to all/most implementations within an abstract base-class representing the interface. When one constructs *multiple* layers like this, it's very useful (and very robust) to have default implementations of some interface methods whilst at the same time explicitly stating: "you must implement this particular area" for any given level -- it's a contractual obligation, made at design-time rather than at implementation-time. become fragile over time. (4) as others pointed out, writing these little glue-wrappers is error-prone, messy, and tedious. That's not good for long-term maintenance. I'm not suggesting that D must support this <g> ... rather I'm trying to discover and understand the rationale for not supporting partial-implementation (and certainly in the absence of mixins). In other words: I need to know the most robust way to handle this in D, before I start writing serious quantities of related code. cheers;
Feb 22 2004
parent Sean Kelly <sean ffwd.cx> writes:
Kris wrote:
 (3) such 'declarative' interfaces are great for plugable systems, where
 multiple people or vendors are involved. For example, you might expose a
 specific kind of device-driver via such an interface, but the concrete
 implementations built by each hardware vendor would at minimum implement
 only their specialized variation [jump(), in this case] whereas run() could
 be common to all/most implementations within an abstract base-class
 representing the interface. When one constructs *multiple* layers like this,
 it's very useful (and very robust) to have default implementations of some
 interface methods whilst at the same time explicitly stating:
 
 "you must implement this particular area" for any given level -- it's a
 contractual obligation, made at design-time rather than at
 implementation-time.
I know it's another kludge, but what about packaging a set of test functions with the library? I think it would be more robust to offer a way to verify that a derived class not only implements such functions but does so correctly. I'd perhaps combine this with pre and post conditions for every function to make use even more obvious. I personally am not averse to expecting users to read and follow the documentation, but then I come from a C++ background where this may be more of a requirement than with other languages. Especially in combination with DBC I think the need for precise documentation is critical. As for why partial implementations aren't supported by D... I have no idea. I tend to avoid such programming methods myself but I can understand how they are useful in certain contexts. Sean
Feb 22 2004
prev sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
"Sean Kelly" <sean ffwd.cx> wrote in message
news:c1b8jd$1ipi$1 digitaldaemon.com...
 Kris wrote:
 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*
Perhaps I'm missing something, but is there some reason the interfaces can't be broken up? Here's an example: class CanRunAndJump -> class CanRun -> interface JumperRunner From what you've said, this may be a case where I'd like to implement the running methods in CanRun and leave the jumping methods for the CanRunAndJump class. Is this right? If so, I don't agree that partial implementation is a good thing. It would make more logical sense to do this: class CanRunAndJump -> class CanRun -> interface RunnerAndJumper class CanRunAndJump -> interface Jumper Or is the goal to provide paritally implemented base classes and force the user to implement the remaining methods? In this case, why not do
this:
 interface RunnerAndJumper {
      void run();
      void jump();
 }

 class CanRun : RunnerAndJumper {
      void run() {}
      void jump()
      in {
          assert( 0 );
          // this function must be overridden in a base class
      }
      {}
 }
Because now someone can create an instance of CanRun, which is wrong because it is notionally abstract, even if not practically so.
Feb 22 2004
prev sibling next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Without a compelling reason, I completely agree with your assessment, and
consider interfaces in D broken. :-(

It shows how much OO programming I've been doing in D - he he - as I was
unaware of this.

(FWIW, I've been doing stacks in several other languages of late. =P )

Percy The Proceduralist

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

 <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
Feb 22 2004
prev sibling parent "Kris" <someidiot earthlink.net> writes:
I think I found a really convoluted way to get around this issue:

interface Wumpus
{
    void wumpus();
}

class Bar : Wumpus
{
    void wumpus(){}; // we're forced to implement
                                // the entire interface
}

class Foo : Bar
{
    abstract override void wumpus(); // aha! it works!
}

main()
{
    Wumpus wumpus = new Foo();  // error: abstract class
}

The 'partial' implementation is in class Bar, but it needs to be wrapped
with class Foo to ensure interface method wumpus() cannot be invoked for Bar
(because it's not intended to be implemented there in the first place!).
That is wacky, highly error-prone, and truly hideous.

Since we can write really ugly code to sidestep this compiler 'policy', can
we just have the real thing instead? Pretty please <g>

- Kris


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

 <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
Feb 25 2004