>For instance with manipulators, after magic-removal, it will be >elementary to over-ride the Model.AddManipulator(), and >Model.ChangeManipulator(pk). So you could then apply RuleDispatch in >your own model, and not need it built-in to Django at all.
You can only override methods that are defined as generic functions. So you will still need RuleDispatch usage in Django - at least those methods that should be overrideable should be defined generic. But the real power of RuleDispatch starts to show if you drop the strict notion of classes and methods and start to build your API again in the "simpler" function-library approach - just using generic functions. Methods will allways have a primary dispatch on the hidden self parameter, while module-level functions will be able to freely dispatch on _all_ parameters. So I think one can really benefit from using RuleDispatch (and I am a rather big fan of this really cool lib PJE wrote!), but I too think it would make sense to build your API for usage with RuleDispatch. Especially since you can then make full use of the really good optimization for dispatching that's in RuleDispatch, which often is much easier to use and as fast as handoptimized dispatching code. Think about our current handling of field types - if the functions producing SQL would just be generic functions, you could dispatch on field types and parameters - and so create a framework of functions that take a query spec and a model and produce SQL from that. But since it would be a bunch of generic functions already, it would be really simple to define your own field types - you would just put your field type and a couple of method specializations into your lib and that's it. No need to monkey patch something, no need to do weird subclassing and method overrides like you currently need to do. Granted, all this can be done without RuleDispatch, too. But that's a non-argument - all what we do with Django could be done with plain Assembler, too, but nobody would be so insane to try that. ;-) RuleDispatch opens up a way to write your code that lifts the limitations of strict class-based extensibility by giving applications a way to override stuff on function-level. Best way to see it might be to say it's a mix of the good extensibility of object oriented programming, combined with the power of monkey patching, all this in a sane and understandable package. bye, Georg
