need ActionForm or HttpParams come to rescue?

question:
1. UnboundMethod#name is not available in ruby1.8.6(seems 1.8.7 is ok).
That’s annoying especially I want to record decorators’ information as metadata, method name as key.
2. how to chain decorator’s result?
ruby_decorator return the last decorator’s result.
but, unlike extlib#Hook, it doesn’t pass result to chain. sinatra use throw keyword to archieve it.

decorators may be helpful in losts situations, and Python’s @ signal makes sense.

think about alter webframework like sinatra:

Post “/articles”
Param :subject, String
Param :body, Text
Respond :html, :json
def create
…
end

from peak.util.decorators import decorate

class Demo1(object):
decorate(a_classmethod) # equivalent to @a_classmethod
def example(cls):
print “hello from”, cls

If language “A” must implement a feature in C code and language “B” can implement it in language B itself, then yes language “B” is more flexible. In this case the claim is that Ruby is more flexible than Python, which is true if this decorator syntax does what is described. No, it is not “the same thing” to use the inconvenient pre-Python syntax. If that syntax were sufficient then Python would never have added decorators to the language. It is to Ruby’s credit if it can implement the modern Python syntax without changing the Python interpreter.

So that’s the disingenuousness on the Python side. If the blog post does what it does, then it is impressive and to Ruby’s credit.

On the Ruby side, I want to be sure that we are talking about something truly analogous to Pythons decorators.

* When I tried to use this construct in an ActiveRecord model, the model stopped working, even before I added any decorated methods. Is that expected? That does not happen with Python decorators.

* Based on my experience above, I believe that if I added this globally, I would break a lot of Rails or Merb code. You implied in the blog post that it was fairly discretionary whether to add it to every class in the system, but I’d appreciate it if you could be explicit about how safe this is or is not.

* It is not clear to me how I apply this to lambda or “top-level” functions

* It is not clear to me how I decorate attr_accessors. Will it work to just put the decorator before the attr_accessor line?

* Does decoration of class methods “just work” as I’d expect?

* Can I decorate classes? Ruby classes are callable, so they should be decoratable.

Once I understand these issues better I’ll be able to know whether this is truly equivalent to the Python feature or just a neat hack that emulates it in simplistic cases.

Before Python got decorator syntax, the convention for decorating was consistent across functions, methods, anonymous functions and classes. In Python 3 it is again consistent for all of those constructs. (for a while in Python 2.x classes were excluded for no good reason) Therefore I believe that Python’s syntax is much more general purpose than the one you’ve demonstrated here.

Great post.

The speculation that such features lead to obfuscated code makes sense in theory, but Ruby has shown that in practice, the opposite is true: a more flexible language allows the programmer to be more *expressive* and the code to communicate its meaning more *concisely*.

Of course, in the hands of a bad programmer, these features can be used to make a mess, as can any other powerful feature. But crippling languages to limit the damage done by incompetents is ultimately self-defeating. It’s much easier to just take away their keyboards.

If only more such language comparison threads were this civilised. Hats off to you all folks.

I know about the difference between __getattr__ and __getattribute__, the code I posted emulates this fine. The implementation will check if the call is an attribute (instance variable) only– you can continue in the else block for pure __getattr__ behaviour.