[MERGE] Support for the decorate argument also in CommandRegistry.register_lazy
lalinsky at gmail.com
Fri Dec 19 22:18:55 GMT 2008
On Fri, Dec 19, 2008 at 8:26 PM, John Arbash Meinel
<john at arbash-meinel.com> wrote:
> John Arbash Meinel has voted comment.
> Status is now: Waiting
> I'm not a big fan of "decorate" because it isn't supposed to mean "replace
> something that already exists", it means "I want to use the one that exists,
> but layer my work on top of it."
> As such, having 2 plugins defining the same command means that one will get
> loaded, but you don't really know which one. (Ordering is not guaranteed.)
> Which is why we don't let 2 plugins provide the same command. Unless you
> really are *decorating* which, at least in theory, means that both
> implementations get used, with one being stacked higher than the other one.
> But more importantly, I don't think register_lazy is compatible with proper
These arguments are completely valid, but I don't agree that
register_lazy is incompatible with "decorate". Python is dynamic
enough to make it possible.
> If you are registering something in a lazy way, there is no way for you to
> pass it the original implementation that you got back. Or at least, if you
> do, then you had to load the new implementation, which means there is no
> benefit to using a lazy registration.
You can return a getter function which will get you the original
class. This means the original implementation will be imported at the
same time your new implementation and you can subclass from it. The
only problem is that it would be nice for this to be consistent with
CommandRegistry.register, which would mean broken API compability for
> I would tend to reject this with the statement "you cannot decorate a
> command in a lazy way". I'm willing to be persuaded, though, which is why I
> voted comment.
No, please vote reject on this in BB.
More information about the bazaar