aaron.bentley at utoronto.ca
Tue Aug 15 19:45:24 BST 2006
-----BEGIN PGP SIGNED MESSAGE-----
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
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar