Steve wrote: > Please take my comments with a grain of salt. I've been out of > Kamaelia mode for several months now as I've had my head buried in > google app engine stuff. I don't have any better suggestions, so I > feel like I don't have the right to complain, but... well it's the > internets right?
Hope you don't mind me sticking my nose in here... I probably have less
experience with Kamaelia than you but Michael doesn't seem to mind. :)
Though you'll want to keep that salt handy.
> Michael, I can appreciate the goal of trying to make basic things
> simple. Your suggestion however feels really ... magical to me. I
> like decorators, really. I use them a lot. But I think decorators
> are best used to apply one flavor change to the decorated function /
> class without significantly changing the decorated item's signature.
> Things like, @run_in_transaction, or @handle_exceptions, or
> @with_logging, or @memoize, or @with_mutex.
>
> All these examples are kind of like aspect oriented programming. The
> core stays relatively the same while some feature is wrapped around it
> relatively transparently. But what you've proposed is really a
> heavily magic @transmogrify. It's turning a function into a class -
> and then a whole lot more.
IMO he's not turning a function into a class. He's turning an iterator into
an iterator. One has a function as a factory and the other has a class, but
that is irrelevant as it is the iterator interface that is key (think
duck-typing).
The idea is to remove the meaningless boilerplate that is required to plug
it into the framework. It is perfectly transparent as the decorator really
does nothing in relation to the logic, it is only an adapter to fit the
generator into the framework.
Though as I've said, I am not really fond of his example either. IMO it is
coming at it from the wrong direction. It seems like it is starting with
the class-based component and just abstracting out some bits. Instead I
think it would work better to come at it from the starting point of a
standard python generator containing your logic that you want to fit into
the framework.
> I've seen lots of very handy decorators that take no arguments (other
> than the decorated function/class). I've seen a lot fewer handy
> decorators that take exactly one additional argument. I've not got
> any decorators that I consider nice to use which take multiple
> additional arguments. Totally side-stepping the issue that I really
> dislike the idea of @decorate function -> class, if you wanted to do
> all that other stuff, may I please suggest you break each piece of
> functionality up into separate decorators. Like...
>
> @inbox
> @inbox('control')
> @outbox('signal')
> @outbox
> class target_class(foo):
> pass
+1
I like the idea of separate inbox/outbox decorators with the optional
argument. It is explicit and allows for composing several of them into one
(eg. the above could be composed into say @pipeline_boxes).
--
John Eikenberry
[...@zhar.net - http://zhar.net]
[PGP public key @ http://zhar.net/jae_at_zhar_net.gpg]
______________________________________________________________
"Perfection is attained, not when no more can be added, but when no more
can be removed." -- Antoine de Saint-Exupery
signature.asc
Description: Digital signature
