Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This looks like even more boilerplate.


Arguably, it can make things easier to read in cases where you want "static" variables, eg. a decorator that synchronises a function with a lock. The lock shouldn't be passed in by the user, nor should it be created in an individual invocation of the decorated function, so having a class to contain the state is useful.


That's a great situation in which to use a class: state you don't want to pass in every time it's used. It doesn't seem to connect to the idea of a decorator, though. Rather than decorating the function, why not just make it a method of the state-managing class? Or if it shouldn't be so closely coupled, why not just pass it the result of invoking a different method of the class?

I don't imply that there isn't a good example of a decorator that should be a class. I just don't think we've seen one on this thread yet.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: