Games people play

Bill Baxter dnewsgroup at billbaxter.com
Tue Oct 3 19:07:58 PDT 2006


John Reimer wrote:
> On Thu, 28 Sep 2006 13:34:15 -0700, Walter Bright 
> <newshound at digitalmars.com> wrote:

> S&S seems like a great pattern, but I'm 
> worried about the urge to implement the current fads into the language 
> just because they're "so great".  Someday, the excitement may fade when 
> an improvement on the pattern surfaces, and we could be left with a 
> feature in there that takes on a form altogether vestigual.  

Yes.  For statically checked S&S, templates & mixins seem like they 
provide basically all that is needed to implement a good solution, 
(maybe there's still some weak reference business that needs to be 
sorted out, but it looks like it's mostly there).  The main wart is that 
you have to have a different template for each number of arguments, 
resulting in repetitive code.  Some form of Variadic Templates would be 
very nice to have there.

So instead of
template Signal(T1) // for one argument ...
template Signal(T1, T2) // for two arguments ...
template Signal(T1, T2, T3) // for three arguments ...
template Signal(T1, T2, T3, T4) // for four arguments ...
template Signal(T1, T2, T3, T4, T5) // for five arguments ...
template Signal(T1, T2, T3, T4, T5, T6) // for six arguments ...
template Signal(etc...

You can just have one template
template Signal(...) // for any number of arguments ...


But something more is needed for Dynamic Qt-like S&S.  Some sort of 
compile-time introspection seems a minimal requirement.  I think some 
way to tag particular method like Qt's "slot:" keyword will also be 
necessary to make it usable.  Anyway you need some way to say "do 
something with this method" and do it at the point of declaration rather 
than in the constructor or elsewhere.

If there were a generic decorator mechanism, that would take care of it 
I think.  'slot' could be a particular user-defined decorator that takes 
a method and adds that method to a static call-by-name table for the 
class, all at compile time.  Decorators also make things like Aspect 
oriented programming, and precondition/postcondition easier.  Can also 
use them to implement things like "synchronized".  Other uses can be 
found here: http://www.python.org/dev/peps/pep-0318/

Anyway decorators are a very useful concept I think.  It's kind of like 
a mixin declared outside a scope rather than inside.  Like a 'mixout'. 
Mixin's inject some code inside something.  A decorator wraps some code 
around the outside of something.

--bb



More information about the Digitalmars-d mailing list