Cumbersome overloading of mixed-in functions

kris foo at bar.com
Sat Aug 19 16:36:17 PDT 2006


Jarrett Billingsley wrote:
> Say I want to add a bunch of (virtual) methods to a class.  All these 
> methods do very similar things, just on different types.  Hmm, sounds like a 
> job for a template.
> 
> So I write up a templated version of the method:
> 
> template FuncTemplate(T)
> {
>     void func(T val)
>     {
>         // do some stuff with val
>     }
> }
> 
> Now I can mix it into the class.  I have, no joke, about 10 or 15 types I 
> want to mix this in as.  So I do this:
> 
> class Foo
> {
>     mixin FuncTemplate!(int);
>     mixin FuncTemplate!(float);
> }
> 
> Oh crap, I can't even go any further right now.  If I try to instantiate the 
> class and call these methods:
> 
> Foo f = new Foo();
> f.func(5);
> 
> I get the error:
> 
> function blah.Foo.FuncTemplate!(int).func conflicts with 
> blah.Foo.FuncTemplate!(float).func at..
> 
> I look up in the spec, and find that it's possible to overload these 
> functions, but it has to be done manually, using dummy mixin names and then 
> aliasing them:
> 
> class Foo
> {
>     mixin FuncTemplate!(int) intFunc;
>     mixin FuncTemplate!(float) floatFunc;
> 
>     alias intFunc.func func;
>     alias floatFunc.func func;
> }
> 
> Foo f = new Foo();
> f.func(5); // yay, works
> 
> Now for the other 12 or 13 types, which means lots of namespace pollution in 
> my class for all the dummy mixin names, and a matching alias for each mixin. 
> And -- oh yeah, I've got 4 or 5 other methods which I want to be templated 
> for the same set of types!
> 
> At which point my class degenerates into four pages of mixins and aliases. 
> I might as well just copy-and-paste the functions and change the parameter 
> type; it'd be a lot clearer.
> 
> What a mess.  There has to be a better way to do this.  I'm thinking 
> something like
> 
> mixin func = FuncTemplate!(int).func;
> mixin func = FuncTemplate!(float).func;
> 
> Kind of an all-in-one mixin/alias without any dummy names, and with a syntax 
> similar to import renaming (and, in effect, a sort of similar effect).
> 
> Or, maybe mixin scoping could be changed so that unnamed mixins have their 
> symbols imported into the local namespace.  After all, if you write:
> 
> mixin FuncTemplate!(int);
> mixin FuncTemplate!(float);
> 
> ..
> 
> f.func(4); // error, ambiguous - in both !(int) and !(float)
> 
> There is _no way_ to disambiguate it unless you use a named mixin - so why 
> bother making it ambiguous with unnamed mixins?
> 
> Although I see this second proposal as a problem with:
> 
> template Temp(T)
> {
>     T x;
> }
> 
> mixin Temp!(int);
> mixin Temp!(float);
> 
> ..
> 
> writefln(x); // ? ambiguous
> 
> Although in this case, I would imagine the normal variable declaration 
> semantics would kick in and say that you were redefining x with the !(float) 
> mixin. 
> 
> 


Better to do it all manually and save yourself the grief. Mixin should 
perhaps be removed from the language until such time that it works in a 
reasonable manner :(



More information about the Digitalmars-d mailing list