On 8/18/05, Shane Hathaway <[EMAIL PROTECTED]> wrote:
> 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.
That remains the case with the proposed change.
> So for this case, I want an inheritance relationship.
We certainly weren't thinking of it as inheritance. In fact, that
makes it impossible to support one particular use case (item 3 in our
> 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.
If the subclassing relationship is the right model, yes. We disagree
that this is the right model.
> Entry #1 of bug #440 demonstrates an inappropriate use of the new
> facility, since the intent of the developer is easily met by existing
The examples are reduced to only show the bug; there certainly may be
additional slots defined in the extended macro, which sounds like your
> However, bug 440 also demonstrates that the syntax is too
> subtle, and perhaps we need a syntax that explains itself better.
Perhaps the define-macro/use-macro combination should be replaced with
something like define-macro/extends-macro (and the former once more
disallowed), and keep the change from the proposed patch.
Let's make sure we've got the bases covered with this:
1. Slots from the "base" macro can still be filled by the template
containing the use-macro.
2. Slots from the "base" macro can be given a new "default filling"
using this in the "derived" macro:
derived default filling
This would only be needed for slots that the derived macro wants to
affect; it's not necessary for slots that should be "inherited".
3. Slots can be filled and not made available to the template
containing the use-macro directive by simply not re-offering them:
Option 3 isn't possible without the changes we've proposed.
Fred L. Drake, Jr. <fdrake at gmail.com>
Zope3-dev mailing list