On Sat, Jul 31, 2010 at 11:17 AM, Greg Ewing
Suppose I write a class Foo, and as a convenience to my users, I want to give it the ability to be json-serialised. If that is done using a generic function, then I need to put a call in my module to register it. But that makes my module dependent on the json-serialising module, even for applications which don't use json at all.
The alternative is just to provide the function but don't register it. But using that approach, every application that *does* use json would be responsible for registering all the functions for all the classes that need to be serialised, including those in library modules that it may not be directly aware of. This doesn't seem like a good situation either.
Hence why most generic function proposals are accompanied by proposals for lazy module import hooks (i.e. delaying the registration until the relevant module is imported). However, the simpler approach is just to recommend that single-dispatch generic functions default to a particular method. "magic method" vs "generic function" isn't actually an either-or decision: it is quite possible to have the latter rely on the former in its default "unrecognised type" implementation, while still providing the type registration infrastructure that allows an application to say "no, I don't want that behaviour in this case, I want to do something different". To be honest, there are actually some more features I would want to push for in ABCs (specifically, a public API to view an ABC's type registry, as well as a callback API to be notified of registration changes) before seriously proposing an official generic function implementation in the standard library. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia