[kris]

IBuffer, IReader and IWriter are interfaces to describe the model exposed by mango.io ~ the relevant concrete classes implement these interfaces, and the interfaces themselves are very useful for decoupling implementation details.

But ... interfaces come at a cost in D. I don't know the exact details but large/long interfaces, combined with deep inheritance, cause the executable to grow at an alarming rate. Then there's a small concern regarding codegen where an interface is cast to a concrete class (happens implicitly, quite a lot in Mango applications).

I spent a good deal of time weighing up pros and cons, testing various alternatives etc, and this is what I came up with:

Keep IConduit as an interface, since it's intended to be applied across a variety of implementations

change IBuffer, IReader, and IWriter to be abstract base-classes instead of interfaces

Making these changes cuts down the executable size quite notably, both in the data-segment and code-segment (the debug version of unittest.d was 260KB smaller). The codegen is better in numerous cases, since there's no need for interface-casts; there's less register spills, and more optimal call-dereferencing (the patch & jump tables are gone).

I like interface abstractions, but would be happy to see these three interfaces become base-classes instead, since I don't expect anyone else to implement compatable classes that couldn't also use the provided base-class. Note that this is currently not the case for IConduit ~ hence it remains as an interface.

Thus, the names IReader, IWriter, IBuffer should actually become AbstractReader, AbstractWriter, and AbstractBuffer respectively. Or perhaps AReader, AWriter, and ABuffer ~ though that sounds a little odd. Such a change would require application code change to these names, and/or use auto wherever possible. Auto is a great feature

As it stands, all code will still compile just fine using the existing names, but be more efficient. The issue is one of naming consistency ~ these classes, speculatively, could not be used as interfaces any more.

What do you think we should do?

[JJR]

Are the abstract classes performing the exact same purpose as the Interfaces were? Is the programmer required to override the abstract methods in the exact same way? Is there an otherwise subtle difference in meaning in this context, between "abstract class" and "interface"?

If there's no real difference in purpose, it seems that the abstract class is still really an interface from the library user's pespective. I'm thinking, therefore, it would be natural to keep the "I" in "IReader" prepended. "AbstractReader" and such, while not too horrible to look at, looks and feels overly wordy. "AReader" just looks plain ugly.

So I vote that the "IReader" naming convention remain. I'm not experienced enough to know if this breaks any cardinal programming rule or not. But it does "feel" acceptible.

-JJR

[JJR]

I guess there is the danger of people assuming the IReader has all the features of a D Interface, if the name is left unchanged. Is there very much of a difference in this context, though? Is there anything that users might try to do with an IReader that they shouldn't if it's an abstract class?

-JJR

[kris]

[JJR]

Okay, I see the problem quite clearly now. Apparently it didn't hit me the first time around.

It would be equivalent to attempting multiple inheritance, which is illegal in D, if one attempted to use the abstract class as if it were an interface. That's bad. So I take back my vote. I obviously didn't think it through far enough.

One of "AbstractReader" or "AReader" will have to do. I don't know which, though. I don't like the looks of "AReader," but I'm beginning to wonder if that form is the way to go afterall. It's hard to compete with brevity.

-JJR

[kris]

I don't think you can take back a vote here ~ But please vote again

[JJR]

Can't take back and can't vote again!

[teqdruid]

The LAST thing we should be doing at this point is renaming things that are used in a bajillion and one places. The API needs to stay as constant as possible, and since IReader et. al. are performing the duties of an interface, they can keep their name, I say.

As for D's interfaces: they suck!!!! I really wanted to use them in the container API, but they really aren't even worth considering. Forget code size and optimization: they outight don't work! Interfaces, it turns out, aren't covariant with ANYTHING, so.... well, I could keep ranting about a huge and obvious deficiency that Walter is fully aware of, but I've been doing nothing but that when it comes to interfaces for the past year anyway.

So I guess my vote is obvious: if it provides any benefits rip out as many interfaces as possible, but keep the names the same!!

[sean]

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.

[Derek Parnell]

[kris]

[kris]

[JJR]

+1 "As above, but rename to AWriter et. al."
-1 "Change to an abstract base-class, but leave the names intact"

A question, though: since "inheriting" multiple interfaces is legal, is there any place in Mango where switching to abstract classes would prevent the user from inheriting from more than one "interface" (now turned abstract class). Or, by design, does mango prevent the need for that.

[kris]

[kris]