[TurboGears] Re: Is Identity too much? I think so.

[Alberto Valverde]

On 23/04/2006, at 17:44, Jeff Watkins wrote: On 23 Apr, 2006, at 11:26 am, Alberto Valverde wrote: Also I should note that you don't *need* to undersand how they work in order to *use* them. On the other hand, if you need to understand the code that uses them, you'll NEVER actually know what the code does unless you understand EVERY instance of the generic function. It's impossible to look at the following code any actually know what it does: @generic() def flip_the_frobble(obj): pass ... def clever_function(obj): flip_the_frobble(obj) What does clever_function actually do? It's impossible to tell, because you have no idea what versions of the generic flip_the_frobble have been created. It's obvious to me from that example that "clever_function" will "flip_the_frobble" on "obj" ;) Now seriously (though that was a "half-joke", I mean, has some truth in it...). If the funtion is specialized properly, it should keep the semantics of the original function. To repeat the first "real-life" example of my previous post: "jsonify" should always return a JSON representation of it's argument, the only thing you don't see it's the actual implementation, which is a *good* point for me as that's all what encapsulation and abstraction is all about. If you need to follow the execution path taken you can use a debugger: In [8]: pdb.runcall(jsonify, 2) > <string>(5)jsonify() (Pdb) s --Call-- > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)<lambda>() (Pdb) > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)<lambda>() (Pdb) --Return-- > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(362)<lambda>()->'__json__' (Pdb) --Call-- > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(491)dispatch_by_truth() (Pdb) > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(492)dispatch_by_truth() (Pdb) --Return-- > /Users/alberto/build/bdist.darwin-8.4.0-Power_Macintosh/egg/dispatch/predicates.py(492)dispatch_by_truth()->[0, None, <functio...x132b1f0>, None] (Pdb) --Call-- > /sw/lib/python2.4/site-packages/TurboJson-0.9.1-py2.4.egg/turbojson/jsonify.py(20)jsonify_simple() -> def jsonify_simple(obj): (Pdb) s > /sw/lib/python2.4/site-packages/TurboJson-0.9.1-py2.4.egg/turbojson/jsonify.py(21)jsonify_simple() -> return obj (Pdb)  There you go, jsonify(2) actually is executed by jsonify_simple at line 21 of jsonify.py. Need anything more? I'm even sure you can inspect a function's AST dynamically but I have not yet found a way to do it... (Anyone got an idea? I'd really appreciate it... :) When languages like C++ offer function overloading, they do it via type inspection. So you can very clearly understand whether the function will be invoked. However, generic functions have no such limitations. This is more or less what dispatch.on does, type checking of a given argument. dispatch.generic is a superset of "on" which gives you even more power as you can go further than argument types and do checks on what those args *can* actually do: "does 'obj' have a 'display' method?" I've heard lots of arguments touting that generic functions increase the flexibility of code, and that's certainly true. However, no one has every cited an example that can only be achieved using generic functions. I've yet to hear an explanation similar to: "I've been looking for a way to flip my frobbles for ages, and thanks to generic functions, I now can!" Of course... but if I take this argument too seriously I can also affirm that there's nothing you cannot do in python/java/c++ that you cannot do in assembler, and way more efficiently. :) No. I'm afraid I classify generic functions under "leads to bad software design". Well, luckily for all think in different ways and have different approaches and biases to problems. And it'll be hell freezing boring :) Regards, Alberto --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "TurboGears" group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~----------~----~----~----~------~----~------~--~---