Fred Drake wrote:
T3 should be filling the slot A defined in T2, and T2 should be filling the slot A defined in T1; this was not happening when T2 extended T1. If T2 did not extend T1, but simply used it, this worked as expected. Having this slot construct behave differently in the case of macro extension is confusing.

My use case for macro extension is as follows: a third party provides a complex macro I'd like to reuse as a macro, but I want to replace only certain slots in my macro. I need my macro to offer all of the slots that the base macro offers, with only a few exceptions. So for this case, I want an inheritance relationship.

In Zope 2, it's not possible to set up this type of macro inheritance relationship. In order for an intermediate macro to offer slots provided by the base, the intermediate macro has to override and re-offer each of the slots. That's a burden when the list of slots provided by the base is changing regularly.

Macro extension is intended to be analogous to subclassing. In a subclass, if you define a method with the same name that a base class provides, your method overrides rather than extends the method in the base class.

Entry #1 of bug #440 demonstrates an inappropriate use of the new facility, since the intent of the developer is easily met by existing syntax. However, bug 440 also demonstrates that the syntax is too subtle, and perhaps we need a syntax that explains itself better.

Zope3-dev mailing list

Reply via email to