Again with the start using.

[Richard Gaskin]

Dar Scott wrote:

> On Wednesday, March 3, 2004, at 10:32 AM, Richard Gaskin wrote:
> 
>> Given that a library should always perform those two checks anyway (to 
>> see if it is the target of the message and whether it's been 
>> initialized already), what is the downside to passing that system 
>> message just as one would usually want to pass all others?
>
> Do you mean in all cases?

I don't know that anything in programming lends itself to absolutes. :)

> Is it really a consensus that certain messages, such as openCard, should 
> pass down the path?  What are those messages?

I picked up the habit of passing system messages from an old book, 
"Tricks of the HyperTalk Masters", and possibly from Thimbleby and 
Colouris' "HyperTalk Programming" (my copy was loaned out many years 
ago, and as happens with many good books it's never come back, and is 
long since out of print).

It proved useful in those days because I would often want to augment 
behavior for an event and found, as those writers suggested, that as 
long as I passed my system messages I'd left an open door to do that. 
Without passing system messages the door is closed, until you write a 
worm to go back and revise the scripts of the objects whose behavior you 
want to change, easier done in one's office than throughout an installed 
based.

But of course, the difficulty is that to rely on messages being passed 
requires that everyone play ball; great for your own team but impossible 
to depend on for libraries designed for use in other people's 
environments.  A lot of the code bases I work on today were inherited, 
mostly ports from other systems, so there are few assurances of 
stylistic consistency.

The solution to this came in 1994 when SuperCard introduced 
frontScripts, allowing you to trap system messages before any other 
object gets them.  This was added to MetaCard not long after.  There are 
rare cases in which it may be especially useful to get the messages 
after the target is done with them, but for the most part frontScripts 
are the optimal choice for trapping system messages in other people's 
environments.

In a frontScript, it is almost always essential that all messages always 
be passed; there may be an exception worth honoring, but in general if 
you don't pass system messages in a frontScript the result will be 
undesirable, as not even the target will get them.

In my own stuff I tend to pass all card- and stack-related messages 
everywhere, and  often don't bother with the "mouse" messages in 
not-frontScript objects.

The libraryStack message is a bit of a Schroedinger's Cat, since on the 
one hand you may want to preserve the native state of things, but on the 
other hand the native state of things doesn't include your stack which 
is the reason that instance of the libraryStack message is sent.  But 
continuing down the rabbit hole, maybe it's a case of "sum ergo passo" 
("I exists, therefore I pass"), in which the existence of the stack in 
the message queue may just as well be seen as a "natural" thing, and 
therefore any outside script monitoring such things should rightfully 
expect the libraryStack message to be comin' down the pike (though I'd 
be surprised if someone writing something so exotic wouldn't prefer the 
greater reliability of a frontScript).

But just as Schroedinger's Cat is an unnecessarily complicated 
discussion for a relatively simple idea, so is that last paragraph. :)

As much as rational minds strive for absolutes, I think a lot of nuances 
surrounding when to pass system messages depend on what you're working 
on and your own personal comfort zone.

Here, when something works I use it, and when it no longer works I write 
a worm. :)  I always pass everything in any script I write for global 
access (frontScripts, backScripts, libraries), and discriminate based on 
contextual considerations in non-shared objects.


As a relevant side note, many messages the IDE relies on are handled in 
backScripts like revGeneral, where you'll find handlers for things like 
the powerful selectedObjectChanged message.  If you're making a drawing 
app and don't pass that message the IDE will not function; this may be a 
downside for those getting started but offers a convenience for pros in 
being able to override IDE behaviors without having to first remove IDE 
scripts from the message path.  As much as I appreciate that convenience 
myself, I would probably make the pros work a little harder if it would 
help protect newcomers, so I wonder if Rev has considered migrating 
those handlers to a frontScript going forward.

-- 
  Richard Gaskin
  Fourth World Media Corporation
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com