Yes, there will most certainly be a totally different concept of properties in Zope 3. But you are right that changing them in Zope2 would be too painful and break too much legacy code 8^(. If you are looking for a way to store large quantities of mapped values, It would not be hard to implement a method using dictionaries or BTrees. You could even write it in such a way that it was compatible with the existing propertymanager/propertysheets interface and thus could use the same managment interface and methods. -Casey Dieter Maurer wrote:
Antwan Reijnen writes:
... accessing properties with "getProperty" and "propertyItems".... Agree, but consider this: when I retrieve a fixed set of data, on propertysheets with varying number of properties (N), the fetchprocedure takes more time when N increases... Why should propertysheet.getProperty('aProperty') take longer on a larger propertysheet?
Currently, PropertySheets store their properties directly as attributes of the parent (i.e. the ZClass instance). Because of this, "getProperty" cannot relay on an "AttributeError" to see that "id" is really a property. It, therefore, calls "hasProperty" and then uses "getattr" on the parent.
Properties have not been conceived as a mass storage concept. Therefore, the properties description is stored as a tuple. "hasProperty" iterates over the tuple and checks for the "id". This is linear in the size of the tuple.
[snip]
There may be new PropertySheets in Zope 3, that do it differently. But, for backward compatibility, the current sheets will almost surely continue to work as you see now.
Dieter