https://code.dlang.org/packages/tardy
https://github.com/atilaneves/tardy

Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism. No inheritance anywhere to be found, which means structs, ints, and arrays can be used with dynamic dispatch (classes as well). It uses the GC by default but users can specify their own allocator type for flexibility, including a built-in "small buffer optimisation" allocator. Sample usage code:

import tardy;

interface ITransformer {
    int transform(int) @safe pure const;
}
alias Transformer = Polymorphic!ITransformer;

int xform(Transformer t) {
    return t.transform(3);
}

struct Adder {
    int i;
    int transform(int j) @safe pure const { return i + j; }
}

struct Plus1 {
    int transform(int i) @safe pure const { return i + 1; }
}

unittest {
    assert(xform(Transformer(Adder(2))) == 5);
    assert(xform(Transformer(Adder(3))) == 6);

    assert(xform(Transformer(Plus1())) == 4);
}

On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> https://code.dlang.org/packages/tardy
> https://github.com/atilaneves/tardy
>
> [snip]

This is pretty cool. Thanks for sharing.

I have a few questions/comments:

1) It might make a good blog post at some point to discuss this and the performance (perhaps with reference to the earlier open methods blog post).
2) It looks like Polymorphic can only take one interface. Would you consider adding the ability to have more than one? I suppose a work-around would be to combine all the interfaces you would want to use into a new interface before combining.
3) Do arrays work, as in Transformer(Adder(2), Plus1()) or [Transformer(Adder(2)), Transformer(Plus1())]

On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> Tardy lets users have their cake and eat it too by not making them have to use classes for runtime polymorphism.

This is one of those things that is so obvious in hindsight. Genius.

On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> https://code.dlang.org/packages/tardy
> https://github.com/atilaneves/tardy
>

Cool stuff!

What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object?

On 6/13/20 2:39 PM, Paul Backus wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
> 
> Cool stuff!
> 
> What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object?

FWIW that could be avoided with extern(C++) classes.

On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> https://code.dlang.org/packages/tardy
> https://github.com/atilaneves/tardy

If this is what you say, it could be used for object-oriented programing with types that are not designed as objects. Not only that, in principle the design should work even at a bare-metal platform as I understand it. I know that practical corner cases would prevent doing the latter without extra work, but impressive nonetheless.

On Saturday, 13 June 2020 at 16:15:49 UTC, jmh530 wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
>> [snip]
>
> This is pretty cool. Thanks for sharing.
>
> I have a few questions/comments:
>
> 1) It might make a good blog post at some point to discuss this and the performance (perhaps with reference to the earlier open methods blog post).

I actually need to benchmark it though!

> 2) It looks like Polymorphic can only take one interface. Would you consider adding the ability to have more than one? I suppose a work-around would be to combine all the interfaces you would want to use into a new interface before combining.

I... completely forgot about that, thanks for bringing it up.

> 3) Do arrays work, as in Transformer(Adder(2), Plus1()) or [Transformer(Adder(2)), Transformer(Plus1())]

Yep:

https://github.com/atilaneves/tardy/blob/d5f1102a6a791e77e0a27ee1a7920166fba8fcc8/tests/ut/polymorphic.d#L222

On Saturday, 13 June 2020 at 18:39:14 UTC, Paul Backus wrote:
> On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
>> https://code.dlang.org/packages/tardy
>> https://github.com/atilaneves/tardy
>>
>
> Cool stuff!
>
> What's the reasoning behind implementing your own vtables instead of using D's built-in object system? Don't want to be stuck inheriting from Object?

That's one reason, but even more importantly this gives the implementation more freedom and potentially more options for client code. I haven't added it yet (mostly due to laziness) but I considered compile-time policies to inline the vtable in the object, or to determine ordering of the vtable and the implementation (might have performance considerations), and a few other things.

Also: more fun to implement, and shows that it can be done as a library.

On Monday, 15 June 2020 at 14:12:17 UTC, Atila Neves wrote:
> [snip]
>
> Yep:
>
> https://github.com/atilaneves/tardy/blob/d5f1102a6a791e77e0a27ee1a7920166fba8fcc8/tests/ut/polymorphic.d#L222

Thanks, I missed that.

On Saturday, 13 June 2020 at 15:11:49 UTC, Atila Neves wrote:
> https://code.dlang.org/packages/tardy
> https://github.com/atilaneves/tardy
>
> [...]
Wouldn't a top type be a better way to achieve this?

-Alex