Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!asente
From: asente@decwrl.dec.com (Paul Asente)
Newsgroups: comp.windows.x
Subject: Re: cleaning up from exit
Message-ID: <2999@bacchus.dec.com>
Date: 12 Mar 90 21:28:51 GMT
References: <9003022256.AA07109@moniz.bcm.tmc.edu> <9003052005.AA24152@expo.lcs.mit.edu> <132650@sun.Eng.Sun.COM>
Organization: DEC Western Software Lab
Lines: 31

In article <132650@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes:
>You might want to make this a more general solution.  Add the notion of
>interposition to the Xt intrinsics as XView does.  Then you just interpose
>on the default clean up procedure to do application specific things.
>
>The concept of "putting this callback before this other one" in the event
>stream is a very powerful tool.  It makes a slight change of behavior very
>easy to accomplish.

It may well be a powerful tool, but it's also a horrible programmer trap.

The biggest problem is that it violates all the abstraction boundaries in
the system.  Think about event handlers, for example.  If you interpose an
event handler that decides not to continue the event handling, you have to
make sure you're not preempting some other event handler that some other,
possibly completely independent, code module has installed.  There are
plenty of cases in widget sets where a widget adds an event handler to its
parent, or to its children, or to some seemingly unrelated widget.  Doing
safe interposition requires an intimate knowledge of the implementations
of all the widget implementations and of the Intrinsics.  Worse, what is
safe today can become disasterous tomorrow as soon as someone modifies the
implementation of any component.

>It's a very clean solution...and would not break backwards compatibility
>since it would be additional functionality.

It's a horrible hack, and adding it breaks widget implementations
everywhere that count on their functions being called.

	-paul asente
	    asente@decwrl.dec.com	decwrl!asente