On 4/24/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote: > When was the last time you added a jsonify rule to an object coming > from a C extension?
I don't think C extensions are necessarily the best example here. Let's look at one of the main drivers for the current jsonify implement: SQLObjects. We *could* have made a new base class that derives from SQLObject and implements __json__. Of course, we'd also have to extend InheritableSQLObject for those who use that. We could use a mixin to share the implementation. But, that has the smell that we're mixing view (JSON) with model. Practicality beats purity, though, so that could slide if it was truly the best and easiest way to do it. The original point about C extensions pretty much holds for *any* Python library that uses its own classes (I'd bet there's a few of those). To add __json__, you'll either need to make your own subclass, again mixing the view with whatever, or do monkeypatching (which I believe is actually the common approach in Rails). RuleDispatch is an approach that keeps view code independent, allows extending of foreign objects without monkeypatching, doesn't require definition of extra classes or adapters (there's a PEP on adaptation which is another solution to this problem), and is performant to boot thanks to Phillip's work in optimizing the implementation. > To clarify, I have nothing against generic functions in general, I > don't know enough about them to criticise them in a meaningful way. > Certainly they have their uses. However, I do know about the jsonify > generic function and in that specific use case, generic functions are > an overengineerd, overkill solution. You just don't jsonify objects > coming from C extensions. You don't add 1500 rules to the function. > You don't (shouldn't) add rules all over the place. And you definitely > SHOULD NOT need a debugger to understand how the damn thing works. I haven't looked at the implementation, but I'd imagine it would be possible to get some kind of listing of the rules for a given function. I don't personally find RuleDispatch to be that hard to understand. Maybe it's just a docs thing. BTW, I could change "You don't (shouldn't) add rules all over the place." to "You don't (shouldn't) add view code all over the place." > I think it is a common theme in much of Turbogears' code. Cutesy over > generalizations that just complicate stuff, when no generalizations > really are needed. It's not pythonic, it's javaesque. There have been several times that I've called "YAGNI" on things that people have wanted to add. Real or at least realistic use cases are more likely to be allowed through than something that is just cool or cutesy. If you see something for which there's no real use case, feel free to bring it up. I like deleting code that has outlived or not proven its usefulness. Kevin --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---
