On Sun, Oct 11, 2009 at 8:09 AM, Michael Sparks - spark...@gmail.com wrote: > > No positive responses. > > Probably not worth the effort in to clean up and merge this in that > case.
The intrawebs are slow don't you know. ;) > However, this looked like one step too far towards voodoo for Steve & > IIRC John agreed. In retrospect, I agree, though it could be a > convenient shortcut. <grin> Thanks for remembering. My brain is slow when coming back to a project I haven't worked with in 6 months. And decorators that take parameters tend to be so much harder for me to reacquaint myself with. I do really like the ease of construction that you're shooting for with these decorators. I would probably use them too for very simple unix shell style transformation components. Most of the kamaelia components I've written have been more involved though. I haven't personally yet needed a utility where I wanted to do some simple composition functions (tail, grep, print, etc) AND thought that I should use a concurrency system like kamaelia instead of a plain python script. I'm sure others have though. > In this case concept comes first, followed by an implementation. Point is > taken though :-) Suggestions for better names welcome. (As noted before) Anyway, I do like the ease of use. And I hate to be another person to harp on the names. Honestly though, it's only easier for me if when I come back after 6 months, it's immediately obvious what's going on in the hidden decorator functionality. Comprehending what _my_ function did and holding in my head the code from somewhere else about what your decorator is doing is just too much for me dull brain. On the otherhand, if the name of the decorator is extremely clear, I don't have to lookup the decorator code as I just take it on faith that it does what it's name says. Some examples would be like: @run_in_transaction @retry_on_exception(max_tries=3) @wrap_with_context_manager So, that said, I'd personally +1 your sketch decorators if they could be given names that were not "what they are" but instead were "what they do". Perhaps: @TransformerGenComponent -> @kComponent_from_generator @blockingProducer -> @kComponent_from_blocking_generator I really prefer the explicit nature of telling me what's going on. I can remember what "TransformerGenComponent" means no problem while I'm coding. When I come back to the project in April though, I'm going to have to lookup the docs for that on what it does and how it does it before I can even read what my code is doing with it. > /me goes off to focus on something else :-) :( I think there is potential usefulness here. If you get it to where you you're satisfied enough with the semantics to use these, I think it would be equally important to back port them in to the Kamaelia code tree wherever possible. That way 1) people reading through the example code would get used to seeing them used and 2) real world usage would help validate their design usefulness. Hopefully late feedback is worth something. :) Cheers, Steve --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "kamaelia" group. To post to this group, send email to kamaelia@googlegroups.com To unsubscribe from this group, send email to kamaelia+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/kamaelia?hl=en -~----------~----~----~----~------~----~------~--~---
