[MERGE] Use slots consistently in InventoryEntry hierarchy -- regenerated against new head. Seeking another reviewer.

[Jan Hudec]

On Wed, May 31, 2006 at 10:18:55 -0400, Aaron Bentley wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Jan Hudec wrote:
> > On Wed, May 31, 2006 at 09:15:28 -0400, Aaron Bentley wrote:
> >>Also, it sounds like there should be namespaces for properties, so we
> >>don't get people accidentally overriding core bzr attributes.
> > 
> > 
> > You are right. Well if I use __dict__ for them (and it should make them
> > slightly faster), they could conflict even with methods of
> > InventoryEntry and I don't like renaming those. 
> 
> How important do you think it is to provide extended properties as
> InventoryEntry attributes?
> 
> I think I would be quite happy with ie.get_value('svn',
> 'svn:mime-type'), or ie[('svn', 'svn:mime-type')].

Well, there is a question how much we want to unify the current
InventoryEntry attributes and the extended properties. If we do not want to
unify them, than I'll improve the __slots__ patch by adding constant None
attributes and lists of applicable attributes to make the code less
type-dependent.

The reason for unifying attributes (like revision, text_sha1 etc.) and
extended properties would be that code either needs a particular attribute,
or both attributes and extended properties. And most of the time handles them
in the same way.

Then making them all attributes would make things a bit faster. The attribute
accessors are implemented in C, while the __get__ method would be in python
and invoking python functions is considerably slower. Also attribute names
are interned strings, which speeds up the hash lookups a bit (interned
strings are compared by pointer and probably (I don't know, but would expect
it) have pre-calculated hash).

> > So I'd say perhaps core
> > properties would use simple names and plugin ones would be required to
> > take form of <pluginname>__<propertname> (double underscore, since plain
> > name can contain underscore as well (eg. text_sha1)). 
> 
> My preference would be to use ':' as a namespace separator, or possibly
> '.'  I think requiring *a* namespace is good, but requiring it to be the
> plugin name would be too inflexible.

No, it would not be required, just recommended. Requirement would be just to
contain the namespace separator.

For the choice of separator, if we want to make them python attributes, than
'__' is the only option. If not, than I'd still prefer something that is
valid XML tag name /without/ XML namespace, which would probably mean '.'.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060531/10a48c41/attachment.pgp