| View previous topic :: View next topic |
| What do you think we should do? |
| Retain the interfaces, and damn the torpedoes! |
|
25% |
[ 2 ] |
| Change to an abstract base-class, but leave the names intact |
|
25% |
[ 2 ] |
| As above, but rename to AbstractWriter et. al. |
|
37% |
[ 3 ] |
| As above, but rename to AWriter et. al. |
|
12% |
[ 1 ] |
|
| Total Votes : 8 |
|
| Author |
Message |
sean
Joined: 24 Jun 2004
Posts: 609
Location: Bay Area, CA
|
 Posted: Tue Dec 06, 2005 6:30 pm Post subject: |
 |
|
Also, template tricks can get around the single inheritance problem most of the time. For example:
| Code: | class Empty {} // dummy parent class
class MyParent(T=Empty) : T {}
class MyDerived : MyParent!(AReader) {} |
In the above example, MyParent has to follow a specific design for this to work, but it's suitable at times. Also, mixins are fantastic for getting around single inheritance problems. If only there were a one-shot way to alias everything in a mixin scope. As for the rest... I've no problems with a search and replace. Takes all of 10 seconds unless something is also deriving from another class. |
|
| Back to top |
|
 |
kris
Joined: 27 Mar 2004
Posts: 1494
Location: South Pacific
|
| Posted: Tue Dec 06, 2005 9:11 pm Post subject: |
|
|
| sean wrote: | | I voted for the last choice but I'd like to qualify it by suggesting that the interface method be reconsidered at a later date, simply because the codegen might improve before D hits 1.0. Unless the abstract base class method proves superior from a usability standpoint at any rate. |
That's a good point. We might leave the names as they are for now and, if interfaces become more efficient, there would be no need for a name change. Of course, that might simply delay a possible name change ~ but still ... |
|
| Back to top |
|
|
Carlos
Joined: 19 Mar 2004
Posts: 396
Location: Canyon, TX
|
| Posted: Wed Dec 07, 2005 8:13 am Post subject: |
|
|
| sean wrote: | | I voted for the last choice but I'd like to qualify it by suggesting that the interface method be reconsidered at a later date, simply because the codegen might improve before D hits 1.0. Unless the abstract base class method proves superior from a usability standpoint at any rate. |
Combining this and the MI "thing" (sorry, can't think of another word), I decided to vote to leave things as they are. I prefer to think that using interfaces is a better design, and that the compiler can get better, or that there'll be more compilers which don't have that problem, so I prefer the better design. |
|
| Back to top |
|
|
pragma
Joined: 28 May 2004
Posts: 607
Location: Washington, DC
|
| Posted: Wed Dec 07, 2005 8:40 am Post subject: |
|
|
I'm in the AbstractWriter camp.
It's really a shame that the current implementation of D gives us inefficent codegen with interfaces; I only wish I knew why Walter decided to go with such a design. Surely there's a tradeoff somewhere?
Anyway, it seems to me that if you have something as elementary as Buffer, Reader and Writer abstract baess, you could inherit and override to your heart's content to create whatever else you needed. They're such fundamental concepts as primitive classes, they may as well have some stock implementation of the interface (as in contract) they support rather than leave it up to the implementer to get wrong.
IMO, adapters and abstract-base classes are a powerful concept that make libraries like Mango all the more useful. I don't think we loose anything from getting rid of the interface versions.
As for supporting the name-change: let's call a spade, a spade. 
_________________
-- !Eric.t.Anderton at gmail |
|
| Back to top |
|
|
teqdruid
Joined: 11 May 2004
Posts: 390
Location: UMD
|
| Posted: Wed Dec 07, 2005 10:04 am Post subject: |
|
|
| pragma wrote: | | As for supporting the name-change: let's call a spade, a spade. |
I disagree. If I'm using a spade like a hammer, 'cause I don't have a hammer, I'll take my most sturdy spade, label it as a hammer, and call it that. (I'm not joking- I've done it) If we change from an actual interface to an abstract class, we're doing it because D lacks interface support that's worth using. This being the case, if we're going to use an abstract class like an interface, let's call it an interface since it essentially is in most respects- other than the keyword that appears before the name! |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
