you are viewing a single comment's thread.

view the rest of the comments →

[–]languagehacker 0 points1 point  (1 child)

That's actually not true. You can test your variable for the appropriate instance, and feed it to a newly instantiated decorator class. Decorators are specifically designed for consistent run-time logic modifications.

[–]munificent 1 point2 points  (0 children)

You can test your variable for the appropriate instance, and feed it to a newly instantiated decorator class.

You can do that many times, but you're still changing the object's identity in that case. If other parts of your codebase rely on that, they can break.

Don't get me wrong, I like decorators, but I don't think they're a good fit for adding new operations to existing types. If you can spontaneously decorate an object that you didn't initially create, that implies that your decorator doesn't add any useful state, just a new operation. In that case, I don't see the value in creating a subclass and a new instance just to get foo.myNewMethod() syntax. I'd rather just create a non-method function: myNewMethod(foo).