I'm curious, did you read and understand the entire code you are commenting on? Your response is like someone saying "I'm sure it won't be good for me but I love the taste of mad cow brains in my dog stew" and then responding with a list of many fine Cambodian restaurants that serve dog stew^*.

The primary feature of the code is not auto generation of methods, but of allowing methods to be replaced at will by assigning a code ref to an invocation of the method to be replaced.

I am not too surprised that there may be rare situations where replacing method implementations willy nilly might be somewhat appropriate. I also suspect that I would manage to avoid such situations by virtue of a more restrained design sense and likely would eventually regret it if I didn't.

But I agree with even the original poster that using the same one mechanism to change attribute values and to replace the methods used to implement an attribute is a violation of good coding practices. Such radically different operations should look different. Further, assigning a value to an attribute should look fairly innocuous while replacing a method implementation long after the object(s) have been created should provide visual cues as to how unusual of an operation it is.

^* Yes, that is a horrible analogy, which is appropriate as also being an analogy of the other horrible analogy. :)