One Python 2.1 idea

[Alex Martelli]

"Moshe Zadka" <moshez at zadka.site.co.il> wrote in message
news:mailman.978224055.28671.python-list at python.org...
> On Fri, 29 Dec 2000 15:44:43 +0100, "Alex Martelli" <aleaxit at yahoo.com>
wrote:
>
> > I'm not claiming it's a _frequent_ application need, to
> > change the behavior of a few methods in certain instances
> > only -- but, I do claim it IS a real need, and I have the
> > scars (and frameworks of Coplienesque C++ templates, because
> > that's the language I was using then) to prove it...:-)
>
> OK, now we're getting somewhere: can you give an example (perhaps
> simplified) of a problem this helps to solve?
>
> this-will-probably-another-fun-and-fruitless-discussion-ly y'rs, Z.

No doubt, yes:-).  Anyway, consider for example a typical
off-the-shelf rich and complex interactive application that
is used for some reasonably complicated task, such as 3D
design of mechanical components and assemblies.  It has, and
exposes to third-party "plug-ins", a lot of objects, such
as various kinds of "buttons", "sliders", and other GUI
artefacts.  You can "conceptually frame" these 'GUI objects'
in many ways, and ditto for the (sometimes corresponding)
'non-GUI' ones that are "in the guts" of the exposed
object-model; but surely presenting them as 'objects' with
'methods' (&c) is one reasonable possibility.

Now, consider a "plug-in" that is transiently activated; when
it IS active, it wants to "tweak" the behavior of just a few,
specifically-identified 'buttons' (&c) and 'internal objects'
out of the zillion instances of those classes that exist at
any given time in the GUI and in the internal engine.  For
example, a 'spline' object, that normally responds to a method
requesting it to distort its shape thus-and-thusly, may need
to be affected by the activation of a certain plug-in (specific
to a certain application area, and certain design or checking
phases) so that the 'shape distortion' happens differently,
while other 'spline-objects' not affected by the plug-in keep
behaving as they previously did -- and the 'affected' object
must revert to 'normal behavior' if the plug-in is deactivated,
as well as keeping normal behavior for a h**l of a lot of other
methods.  Such needs may apply, depending on the specific
area of application and the purposes of the plug-in, to any
(small) subset of method of any (small) subset of objects
that the application's object-model exposes.

The simplest way to frame this, is to tell the plug-in authors
that they can just substitute their own code for any given
subset of methods of any exposed objects they can identify,
and 'restore' the original behavior when needed.  Of course,
I cannot *implement* it this way if the language or framework
in use is not flexible and dynamic enough to directly expose
this conceptualization -- I have to insert some layer of
"indirectness", and I may even have to expose it directly to
the plug-in's programmer, again depending on expressive power.

For example, to satisfy such a general need in a COM framework,
I might reverse the 'natural' conceptual framing like a glove,
and expose the whole customizability in terms of "events": any
time an application-object is required to do something, it can
first try to generate a 'BeforeSomething' event -- if any
plug-in has registered a listener for such events on the object,
it gets a chance to block them and substitute its own code; and
after nobody's blocked it, and the object's method has run, it
can further generate an 'AfterSomething' event, so that any
listener may optionally examine the resulting object state and
possibly effect some further changes to it.  It IS a powerful
alternative framing, and VBA programmers have apparently learned
to think in these terms, since this is basically the way one
does VBA customization of any Microsoft Office application.

But changing a given object's response to a certain request
more directly, by "temporarily plugging in your own code in
stead of the original's", is simpler and more natural _if the
language/framework/object-model that is in use affords it_,
particularly if the target audience of plug-in programmers
are not used to thinking in terms of "intercepting events,
possibly blocking the normal resulting response" and the subtle
before/after distinctions -- the 'synchronous' nature of "the
application's framework calls method M on object O, and code
is executed to respond to it" is much more linear than "the
application's framework calls method M on object O, then object
O broadcasts event BeforeM to all current listeners, stopping
if the Cancel parameter is ever set, then, if Cancel was NOT
set, O's code [that you can't change] is executed to respond
to the original request, and finally object O broadcasts event
AfterM to all current listeners".  The additional generality
of the latter approach (e.g. as permitted by the multi-listener
situation inherent in the 'broadcast') ensures it cannot be
quite as linear and simple as the former one for situations
that DO fit the former (which are pretty frequent ones).


Alex