[phobos] AutoImplement: Shouldn't it be a mixin template?
Andrei Alexandrescu
andrei at erdani.com
Sun Jan 2 14:45:09 PST 2011
That could be done like this:
class ShimClass : Interface1, Interface2 {}
alias AutoImplement!(ShimClass, ...) Class;
Also, I see there's no example of actually using AutoImplement. That
means searching with Google and that page for AutoImplement will not
find a simple and meaningful example. Shin?
Andrei
On 9/7/10 10:54 PM, David Simcha wrote:
> The AutoImplement functionality in std.typecons is currently a class.
> This severely and unnecessarily limits its usefulness in the following
> cases:
>
> 1. You want to implement more than one interface automagically.
>
> 2. You want to implement stuff automatically, but also add more to the
> class. For example, maybe you want to add some members to the abstract
> base class before auto implementing, and maybe override some of the auto
> implemented functionality. Of course you could define 3 levels of
> inheritance (the abstract class with all the extra members, the auto
> implemented stuff, and the class with stuff overridden) but this is
> horribly verbose.
>
> 3. You want to evaluate the automatically implemented functionality in
> some scope other than std.typecons, so you can import stuff.
>
> Shouldn't we just make AutoImplement a mixin template instead? This can
> be done trivially by mixing the string mixin currently used to implement
> it into a mixin template's scope. It seems like it would solve all the
> relevant problems. Then we could do stuff like:
>
> interface Interface1 {
> void fun();
> void gun();
> }
>
> interface Interface2 {
> void hun();
> }
>
> class Class : Interface1, Interface2 {
> mixin AutoImplement!(Interface1, generateEmptyFunction,
> isAbstractFunction);
> mixin AutoImplement!(Interface2, generateEmptyFunction,
> isAbstractFunction);
>
> // Override the automatic implementation of fun() taking advantage of
> // template mixin name lookup rules.
> override void fun() {
> writeln("Overridden.");
> }
> }
>
> The killer use case for this would be automatic forwarding for the
> decorator pattern. You could just mix in an AutoImplement that forwards
> all of your decorator interface functions to the encapsulated object,
> and then override whichever ones you need to.
> _______________________________________________
> phobos mailing list
> phobos at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/phobos
More information about the phobos
mailing list