I was implementing a framework and I found that I wanted two things.
 - A strong set of interfaces so that I can get what I want from a variety of sources.
 - Some basic implementations of these interfaces.

For example, say I was writing a database class.  I could either name the interface Database and call the class DatabaseImplementation or something but that is ugly.  If I call the interface IDatabase, the Database class looks nice but I need to convince users to write functions that take IDatabases not Databases.

I was wondering if there was any way to implement a default implementation.  This way, I could create my Database interface and classes could implement that but if you called `new Database()` you would still get a basic database.

I thought about doing it in different modules but it just gets messier as you have to fully qualify all of the names so both look ugly.  I though about overloading the new operator for the interface but it would have to be final and that would mess everything up.  I though about a meathod like `Database.newDefault()` but that is messy and has no meaning in a derived class.

I couldn't find anything about this so I was wondering what you would recommend.  Should I just pick a naming scheme?

On 02/16/2012 04:01 AM, Kevin wrote:
> I was implementing a framework and I found that I wanted two things.
> - A strong set of interfaces so that I can get what I want from a
> variety of sources.
> - Some basic implementations of these interfaces.
>
> For example, say I was writing a database class. I could either name the
> interface Database and call the class DatabaseImplementation or
> something but that is ugly. If I call the interface IDatabase, the
> Database class looks nice but I need to convince users to write
> functions that take IDatabases not Databases.
>
> I was wondering if there was any way to implement a default
> implementation. This way, I could create my Database interface and
> classes could implement that but if you called `new Database()` you
> would still get a basic database.
>
> I thought about doing it in different modules but it just gets messier
> as you have to fully qualify all of the names so both look ugly. I
> though about overloading the new operator for the interface but it would
> have to be final and that would mess everything up. I though about a
> meathod like `Database.newDefault()` but that is messy and has no
> meaning in a derived class.
>
> I couldn't find anything about this so I was wondering what you would
> recommend. Should I just pick a naming scheme?

As a user (read developer), I'd rather code to the generic interface when possible. I like that concrete implementations looks rather long and ugly :)
I don't think you should be worried that your users is using direct implementations rather than the interface - their problem!

Remember that in D, interfaces can contain implementations that only uses static methods on the interface:

interface DB {
    @property string name();
    // interfaces can have implementations
    static DB createDefault() { return new GenericDB(); }
}

class GenericDB : DB {
    @property string name() {
        return "generic"; }
}

class MySQLDB : DB {
    @property string name() {
        return "mysql"; }
}

void main() {
    assert(DB.createDefault().name == "generic");
    assert((new MySQLDB()).name == "mysql");
}

On 2012-02-16 04:01, Kevin wrote:
> I was implementing a framework and I found that I wanted two things.
> - A strong set of interfaces so that I can get what I want from a
> variety of sources.
> - Some basic implementations of these interfaces.
>
> For example, say I was writing a database class. I could either name the
> interface Database and call the class DatabaseImplementation or
> something but that is ugly. If I call the interface IDatabase, the
> Database class looks nice but I need to convince users to write
> functions that take IDatabases not Databases.
>
> I was wondering if there was any way to implement a default
> implementation. This way, I could create my Database interface and
> classes could implement that but if you called `new Database()` you
> would still get a basic database.

You can create an abstract class that implements some parts of the interface. Then the user (developer) is free to choose to inherit from the interface or the abstract class.

> I thought about doing it in different modules but it just gets messier
> as you have to fully qualify all of the names so both look ugly. I
> though about overloading the new operator for the interface but it would
> have to be final and that would mess everything up. I though about a
> meathod like `Database.newDefault()` but that is messy and has no
> meaning in a derived class.
>
> I couldn't find anything about this so I was wondering what you would
> recommend. Should I just pick a naming scheme?

About the naming scheme I would go for this:

interface Database {}
abstract AbstractDatabase : Database {}

class Implementation : Database {}
class Implementation2 : AbstractDatabase {}

Possibly suffix the implementations with "Database".

class ImplementationDatabase : Database {}
class Implementation2Database : AbstractDatabase {}

But it feels a bit redundant with "Database" in the implementation name.

-- 
/Jacob Carlborg

On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote:
> You can create an abstract class that implements some parts of the interface. Then the user (developer) is free to choose to inherit from the interface or the abstract class.

Which results in a classic problem that you run into in Java all the time when dealing with event-based programming (since it deals with events via interfaces). If you have a class that only really needs to implement a couple of the functions from the interface of an event listener, then you can derive from the class which implements it and gives them all empty bodies. But if you need your class to implement multiple such interfaces, you can only do that with one of them, which gets really annoying, because then you have to create a bunch of empty method bodies yourself. It's one of the classic examples where multiple inheritance would be desirable.

The current situation in D is exactly the same (though, since we don't have a swing equivalent, I don't think that it's something that D programmers are frequently running into at the moment). AIUI, Java is going to be adding the ability to give interfaces default implementations such that that implementation is effectively copy-pasted into your class when you implement it and don't provide an implementation yourself (rather than the function in your class overidding it as would be the case with an abstract class). This nicely solves the event listener problem, and D doesn't have that. I assume that that's the sort of thing that the OP is looking for.

Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations.

- Jonathan M Davis

On Thursday, 16 February 2012 at 10:24:44 UTC, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote:
>> You can create an abstract class that implements some parts of the
>> interface. Then the user (developer) is free to choose to inherit from
>> the interface or the abstract class.
>
> Which results in a classic problem that you run into in Java all the time when dealing with event-based programming (since it deals with events via interfaces). If you have a class that only really needs to implement a couple of the functions from the interface of an event listener, then you can derive from the class which implements it and gives them all empty bodies. But if you need your class to implement multiple such interfaces, you can only do that with one of them, which gets really annoying, because then you have to create a bunch of empty method bodies yourself. It's one of the classic examples where multiple inheritance would be desirable.
>
> The current situation in D is exactly the same (though, since we don't have a swing equivalent, I don't think that it's something that D programmers are frequently running into at the moment). AIUI, Java is going to be adding the ability to give interfaces default implementations such that that implementation is effectively copy-pasted into your class when you implement it and don't provide an implementation yourself (rather than the function in your class overidding it as would be the case with an abstract class). This nicely solves the event listener problem, and D doesn't have that. I assume that that's the sort of thing that the OP is looking for.
>
> Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations.
>
> - Jonathan M Davis

BlackHole from std.typeconst can be used for that purpose.



import std.typecons;
interface A
{
   void a();
   int b(void* arg);
}

interface B
{
   int c(string arg);
}

interface Common : A, B
{
}

class Good : BlackHole!Common
{
   override int b(void* arg)
   {
       return 0;
   }
}

void main()
{
   auto g = new Good;
   g.a();
   auto i = g.b(null);
   auto j = g.c("Hello");
}

On 2012-02-16 11:23, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 11:11:20 Jacob Carlborg wrote:
>> You can create an abstract class that implements some parts of the
>> interface. Then the user (developer) is free to choose to inherit from
>> the interface or the abstract class.
>
> Which results in a classic problem that you run into in Java all the time when
> dealing with event-based programming (since it deals with events via
> interfaces). If you have a class that only really needs to implement a couple
> of the functions from the interface of an event listener, then you can derive
> from the class which implements it and gives them all empty bodies. But if you
> need your class to implement multiple such interfaces, you can only do that
> with one of them, which gets really annoying, because then you have to create
> a bunch of empty method bodies yourself. It's one of the classic examples
> where multiple inheritance would be desirable.

Interfaces and abstract classes is the simple solution. If the class hierarchy is quite simple won't be a problem. It looks like it is quite simple in this case. Or one could skip the interface completely perhaps.

> The current situation in D is exactly the same (though, since we don't have a
> swing equivalent, I don't think that it's something that D programmers are
> frequently running into at the moment). AIUI, Java is going to be adding the
> ability to give interfaces default implementations such that that
> implementation is effectively copy-pasted into your class when you implement it
> and don't provide an implementation yourself (rather than the function in your
> class overidding it as would be the case with an abstract class). This nicely
> solves the event listener problem, and D doesn't have that. I assume that
> that's the sort of thing that the OP is looking for.

Since D have delegates I would use those for event handling and not listeners. I think they are a much better fit, as long as you don't have to force the user to handle many different events on the same object.

> Now, if you use template mixins, I believe that it's possible to use that to
> mixin default implementations for the functions in an interface, which should
> solve the problem for D. So, that's probably good enough for D without having
> to make it so that interface functions can have default implementations.
>
> - Jonathan M Davis

Template mixins cause their own problems. You can't overload methods with template mixins, may it's possible to get around that with aliases, I don't remember.

-- 
/Jacob Carlborg

On Thursday, February 16, 2012 13:26:59 Jacob Carlborg wrote:
> Since D have delegates I would use those for event handling and not listeners. I think they are a much better fit, as long as you don't have to force the user to handle many different events on the same object.

Oh, I'm not necessarily arguing that using interfaces far listeners is the way to go (in fact, I agree that delegates would be much better). It's just that that's a prime example of a situation where you want default implementations for interface methods, since with single inheritance, you can't derive a class from multiple classes which give you default implementations for interface methods.

> > Now, if you use template mixins, I believe that it's possible to use that to mixin default implementations for the functions in an interface, which should solve the problem for D. So, that's probably good enough for D without having to make it so that interface functions can have default implementations.
> 
> Template mixins cause their own problems. You can't overload methods with template mixins, may it's possible to get around that with aliases, I don't remember.

I thought that you could, since they can be virtual, unlike templated functions. I don't know though. It's not something that I've really had to worry about - particularly since so few of my D programs need classes, let alone interfaces (because most of my D programs are small).

- Jonathan M Davis

On 2012-02-16 20:05, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 13:26:59 Jacob Carlborg wrote:
>> Since D have delegates I would use those for event handling and not
>> listeners. I think they are a much better fit, as long as you don't have
>> to force the user to handle many different events on the same object.
>
> Oh, I'm not necessarily arguing that using interfaces far listeners is the way
> to go (in fact, I agree that delegates would be much better). It's just that
> that's a prime example of a situation where you want default implementations
> for interface methods, since with single inheritance, you can't derive a class
> from multiple classes which give you default implementations for interface
> methods.

Ok, I see. I got the impression that you preferred listeners.

>>> Now, if you use template mixins, I believe that it's possible to use that
>>> to mixin default implementations for the functions in an interface, which
>>> should solve the problem for D. So, that's probably good enough for D
>>> without having to make it so that interface functions can have default
>>> implementations.
>>
>> Template mixins cause their own problems. You can't overload methods
>> with template mixins, may it's possible to get around that with aliases,
>> I don't remember.
>
> I thought that you could, since they can be virtual, unlike templated
> functions. I don't know though. It's not something that I've really had to
> worry about - particularly since so few of my D programs need classes, let
> alone interfaces (because most of my D programs are small).
>
> - Jonathan M Davis

Note that I'm saying "overload" not "override".

-- 
/Jacob Carlborg

On Thursday, February 16, 2012 20:17:22 Jacob Carlborg wrote:
> Note that I'm saying "overload" not "override".

Ah, so you did. Yes, that would probably be a problem, though aliases can probably fix it (that's how you deal with having all of the overloads for a function in the same overload set for a derived class when you only override some of them). But I haven't tried it, so I don't know.

- Jonathan M Davis

On 2012-02-16 22:08, Jonathan M Davis wrote:
> On Thursday, February 16, 2012 20:17:22 Jacob Carlborg wrote:
>> Note that I'm saying "overload" not "override".
>
> Ah, so you did. Yes, that would probably be a problem, though aliases can
> probably fix it (that's how you deal with having all of the overloads for a
> function in the same overload set for a derived class when you only override
> some of them). But I haven't tried it, so I don't know.
>
> - Jonathan M Davis

I know it works with derived classes but I haven't tried it with template mixins.

-- 
/Jacob Carlborg