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 ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
