• Kris (35/35) Feb 22 2004 Much to his credit, Walter has often noted specific reasoning for the
• Andy Friesen (5/15) Feb 22 2004 Abstract classes work great in D. The problem is that you can't
• Sam McCall (2/12) Feb 22 2004 And Java's collections.
• Hauke Duden (25/64) Feb 22 2004 I agree. It makes interfaces very hard to use, since you cannot write
• SpookyET (5/52) Feb 22 2004 Interfaces are good for contracts, take a look at that plugin system i
• Ben Hinkle (76/76) Feb 22 2004 "Kris" wrote in message
• Ant (9/18) Feb 22 2004 - The concept of abstract class is crippled (at least how I'm use to the...
• Brad Anderson (7/11) Feb 22 2004 John Reimer and I *are* those poor folks, and it's becoming a problem. ...
• Ant (5/11) Feb 22 2004 neither.
• Ant (5/18) Feb 22 2004 BTW do you remember I warned about this problem a couple of months
• Andy Friesen (4/9) Feb 22 2004 I'd throw an InternalError or somesuch until we can get Walter to cave
• Matthew (6/14) Feb 22 2004 idea?
• Sean Kelly (26/29) Feb 22 2004 Perhaps I'm missing something, but is there some reason the interfaces
• Kris (46/68) Feb 22 2004 Inline:
• Sean Kelly (14/27) Feb 22 2004 I know it's another kludge, but what about packaging a set of test
• Matthew (5/35) Feb 22 2004 this:
• Matthew (17/52) Feb 22 2004 Without a compelling reason, I completely agree with your assessment, an...
• Kris (36/71) Feb 25 2004 I think I found a really convoluted way to get around this issue:

"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

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

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

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

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/

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

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

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?

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

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

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

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

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
     }
     {}
}

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

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

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

"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

"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