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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jan Hudec wrote:
> On Tue, May 30, 2006 at 19:23:44 -0400, Aaron Bentley wrote:
>>a) Each InventoryEntry could provide a get_attribute_list() method,
>>which would provide a list of name,value tuples.
>>
>>b) Each InventoryEntry could provide a set_attributes() method, which
>>would take as an argument an object that it can store its attributes in
> 
> 
> These two are a good idea. Thanks.
> 
> I want to do the properties stuff. I originally wanted to convert the
> base attributes to slots (with the patch I sent) and add a proplist
> dictionary with the other ones (executable + properties defined by
> plugins (eg. newline-style, keyword expansion, charset conversion, unix
> permissions etc.). Now that would add a dictionary back, right? 

It seems almost certain.

The reason I mentioned a list of tuples rather than a dict is because I
think it would be a good idea for attributes to have a defined order.

But maybe you just have to provide an iterator that provides results in
sorted order.

> And
> quite many operations would have to look at it anyway. So this leads me
> to thinking that perhaps I should unify the core and non-core attributes
> and use methods like you suggested for everything, not just the
> proplist.

This sounds like it would be slower than using slots, and possibly
slower than normal variable access, so please benchmark if you make that
kind of change.

Also, it sounds like there should be namespaces for properties, so we
don't get people accidentally overriding core bzr attributes.

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

iD8DBQFEfZbw0F+nu1YWqI0RAmsBAJ95l+Z5jQ7L9e1G6AKbAZv4B0ptOQCggmgL
wxAEfLiKq42IuGzGV7IH++4=
=KVtk
-----END PGP SIGNATURE-----