You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I was finding the decorator for ImageOpener confusing.
Pros for the decorator:
* Adding allowed `valid_exts` and specifying how it should be opened happen in
the same place (decorator at top of class);
* Using a decorator allows change of internal storage of the ImageOpener
class.
Cons:
* Decorators can be hard to read, especially when the decorator is a function
call (so the decorator returns a decorator);
* It's hard to see at a glance which extensions are valid, because the
decorator is at the top of the class, and adds later to `valid_exts`,
whereas the apparent definition of `valid_exts` is after the docstring;
* The decorator has to know about the internals of the class (in this case,
the `valid_exts` attribute);
* The role of the decorator is to signal that a certain extension has to be
opened in a certain way, but it seems a bit odd that this signal also adds
the extension to the class. To me it seems more natural to make this signal
a line of its own, next to the `valid_exts` definition;
* Modifying the ImageOpener dictionary directly doesn't stop us from making
the dictionary a property or another object type, and changing the
underlying storage;
* No decorator means less code.
0 commit comments