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
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