Decorator Maker is working. What do you think?

Ron_Adam radam2 at tampabay.rr.com
Tue Apr 5 17:32:12 EDT 2005


On 5 Apr 2005 00:35:45 -0700, "Kay Schluehr" <kay.schluehr at gmx.net>
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]





More information about the Python-list mailing list