[merge] LazyFactory

Aaron Bentley aaron.bentley at utoronto.ca
Tue Aug 15 19:45:24 BST 2006

Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> Registry would not be the exact class for doing option handling.
> The important part is that they extend from a common Registry interface.
> Just for consistency across bzr.

I'm not sure such consistency will work out well.

> Right now, we have log formats, merge formats, transports, branch
> formats, repository formats, ... All which have slightly different
> semantics about how to add a new one.

Yeah, and all but transports need to be exposed as EnumOptions.  So I'm
inclined towards One Registry Class To Rule Them All.

> We certainly can have a registry that preserves the order that keys are
> registered.
> I would like this to be something that you can ultimately use. So what
> do you need for things like 'per-command defaults'.

Perhaps that is actually best handled before we hit the Registry.  I was
thinking I needed to be able to get None or KeyError, but I had it

> The OptionRegistry would probably be extended so that it used something
> more like:
> def __init__(self, option_name):
> def register(name, help_text, klass):

I was thinking a factory function is all I need.  Is there are reason
for them to be classes?

> So when you register a new entry, you are required to pass in the help
> text, etc. And the name of the option is supplied when creating the
> option list. It would also be possible that individual option lists need
> to subclass OptionRegistry, and then we use self.__class__.__name__, but
> I think a parameter is better than a subclass.

Yes, I'd prefer to always require a switch name.  It seems better to
separate the UI representation from the core functionality, at least a
little bit.

Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list