On 5 Apr 2005 00:35:45 -0700, "Kay Schluehr" <[EMAIL PROTECTED]> wrote:
>Ron_Adam wrote: >> Ok... it's works! :) >> >> So what do you think? > >Not much. As long as You do not present any nontrivial examples like >Guidos MultiMethod decorator or an implementation of the dispatching >"case" decorator I proposed that would benefit from factoring into pre- >and postprocessing the pattern has only limited use and worse it >suggests a misnomer: it obscures the semantics that is clearly >functional/OO not procedural. > >Regards, >Kay No good points at all? :/ Are you saying I need to present a non trivial example such as Guido's MultiMethod decorator, or the one you proposed? If I'm not mistaken, there is a difference. Those axamples are specific applications to solve specific problems using decorator expressions. While what I'm attempting here is a general purpose object in which many specific uses could more easily be built with. What about commonly used trivial cases? As a whole are they not non-trivial? How is it limited? I'm still not sure when, and what type of things, should and should not be done with decorators. It seems to me they may be good tools for validating inputs and outputs, and for getting data on program performance. In those cases, it would be good to be able to disable them when they aren't needed. Another use is to redefine a decorator as needed to adapt a function to a specific input or output. Is that what Guido's multimethod does? And they might also be used as a way to change the behavior of a group of related functions all at once at run time in order to save a lot of code duplication. I also think they could be abused easily and used when it would be better to just use a class to do it in the first place. Cheers, Ron] -- http://mail.python.org/mailman/listinfo/python-list
