Hi Christian,

So, I'm wondering:

- Is it harmful to have two fields with the same order like this when they share a name?

"Sharing" a name sounds weird. The attribute get's overriden and the
field from the base class isn't considered anymore.

Right, that's what I meant. Except that if you access IBase['b'].order it will be equal to IDerived['b'].order, though I don't think this is necessarily a problem.

- Should this be the default behavior when deriving interfaces from one another like this?

I'm not sure about that. IIRC the general issue here is that there's a
*global* counter involved when determining the order of fields.

Right, but I think the end result is counter-intuitive in the case I'm describing. I don't know if the global (non-thread-safe) was just the easiest implementation or a deliberate choice.

One way to do that would be to fire an event at the end of InterfaceClass.__init__() and have an event handler to fix the order, though that'd make zope.interface dependent on zope.event which is probably not desirable.

We could simulate the event handler in another way, of course, e.g. by having the interface initialiser loop over its attributes and see if they support e.g. an IOrderAware interface and call a method on it, and have Field implement this.

Another way to to that would be to derive the `order` attribute of a
using the MRO (is that the mechanism relevant here?) of the class it
belongs to find inheritance ancestors and use their `order` attribute
instead. That behaviour could also easily be controlled using a flag of
the field.

Yes, this could be an option. So, 'order' becomes a property and looks up (any maybe caches) the order from its base interfaces - loop through base interface in MRO, look for field with same name, if so, return its 'raw' order, otherwise, return self's 'raw' order.

I'd be willing to implement this (if I can find the time) if people agree that it's a good idea.

Martin

--
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

_______________________________________________
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )

Reply via email to