[TurboGears] Re: Generic functions
On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on I think you meant to say C++, not C. In any evernt, your primer is rather lopsided. If your goal is really education rather than advocacy, you'd note the drawbacks of using generics. There are more than one, and if you really understand generics, then you can probably enumerate them. To me, the biggest drawback is their resistance to static analysis (the human kind!). True, Python already has features that make static analysis difficult, but there's no reason to make the problem worse if you don't have to. Generics can be very useful, but so far in TG I haven't seen a case in which the cure is better than the disease. -- Tim Lesher [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
On 23/04/2006, at 19:41, Simon Belak wrote: Seeing a positive correspondence between people who disdain generic functions and people who do not know what exactly generic functions are, I decided to write a little primer in hopes FUD propagation will make way for an augmented discussion. Thanks for giving us some formal background the topic for better understanding, nice to hear a sound voice on this :) The aforementioned rules usually also establishing a selection hierarchy (more specific is often the governing relation) to reduce ambiguity. As I've mentioned in the other (probably hijacked) thread. I would like to know if there is a way to inspect the current state of the rules hierarchy. To word it in another way: to see which rules are present in a function's decision tree. I'm mostly interested for debugging or maybe dynamically generating the rule I want to insert to avoid ambiguities. Some pointers to specific docs of RuleDispatch (couldn't find any) or in which part of the code I should start looking at will be much appreciated. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: 1) type dispatch (also called multiple dispatch and overloading) A function is selected depending on types of arguments passed. Examples: C, Py3k?, PyProtocols.dispatch.on I think you meant to say C++, not C. Yes, of course. In any evernt, your primer is rather lopsided. If your goal is really education rather than advocacy, you'd note the drawbacks of using generics. There are more than one, and if you really understand generics, then you can probably enumerate them. Yes, there are, but all are mostly implementation specific. To me, the biggest drawback is their resistance to static analysis (the human kind!). True, Python already has features that make static analysis difficult, but there's no reason to make the problem worse if you don't have to. I assume we are talking about border cases where function resolution order is not clear. Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: Jeff Watkins wrote: Generics can be very useful, but so far in TG I haven't seen a case in which the cure is better than the disease. Generics != generic functions Ack. You're absolutely correct. I meant generic functions, not generics. Blame it on trying to reply while packing up to move, rather than a misconception, though. :-) -- Tim Lesher [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
Tim Lesher wrote: On 4/23/06, Simon Belak [EMAIL PROTECTED] wrote: I assume we are talking about border cases where function resolution order is not clear. That's one situation, but... Yes, it is harder, however why would you want to do static human analysis in a dynamic language? Fire up an interpreter prompt and experiment. The bigger problem is that in a interpreter, it's often difficult to duplicate the conditions that are prevalent during runtime of a large Python application. This is less a problem with the theory of generic functions (which is mathematically sound, of course), than with their implementation and use in Python. In my experience, interactive live development is a lot harder in Python environments that it is in Lisp or Smalltalk environments, simply because many Lisp and Smalltalk applications are _designed_ to be developed in this way: they are usually comprised of smaller functions, with less state and fewer side effects (pre-optimization, of course), and their standard libraries support that idiom very well. On the other hand, Python applications tend to be a mixture of C-style procedural libraries (mostly because of the C-runtime-flavored Python standard library), C++ and Java-style object-oriented classes, and a small slice of functional programming. That makes them harder to debug than either environments based on functional languages (where a live REPL is often sufficient for most,but not all, debugging) or C-like environments (where static analysis is often sufficient for most, but not all, debugging). This isn't an anti-Python rant (although it's starting to smell like one!). My opinion is that generic functions are harder to work with in Python than they are in the environments from whence they originated (due to the environment, not the functions themselves), and for that reason, they can't be used as lightly as they are in their native habitats. Can't argue with that, however as an avid (smug ;)) Lisper I would much rather TG moves towards a live environment (where it belongs) than to relinquish my toys, erm I mean powerful tools. Cheers, Simon --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Generic functions
On 23/04/2006, at 21:34, Simon Belak wrote: As far as code goes, I would start either at dispatch.functions.parse or dispatch.interfaces.DispatchError. I think I've just found the answer with help(dispatch): TODO * Support DAG-walking for visualization, debugging, and ambiguity detection Thanks, 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 -~--~~~~--~~--~--~---
