Jan Schenkel and I have been enjoying a discussion of this in private email, and this background on the issue from an email to him may be of interest to the readers here:
-------------------------------------------------------------------------- Using "the result" over "it" in the context given appears to be an exception to the conventions of the language, at least to this scripter only halfway into his morning coffee (this appearance may change as I get closer to the bottom of the cup). While "the result" is not always reserved for error info, in most cases it is. But even more relevant here is the convention elsewhere in the language of using "it" to return values from commands, esp. commands that create things. The integer returned by "send <message>" is effectively an ID. While the thing being created is not an object per se, commands that create objects return the ID of the newly created object in "it". Accordingly, many of us are in the habit of checking "the result" for error info, and have come to expect "it" to contain non-error information for commands that create things, esp. IDs. IMHO, the original poster's expectations appear reasonable given these conventions, unless there is some other linguistic rule at play that I'm not taking into consideration. Understanding the logic of this distinction would seem useful for both experienced scripters and newcomers alike. Being one of those "usability nuts", in cases of cognitive dissonance I tend to favor user expectations over the designer's intentions, unless there's a good argument for the design. To Raney's and Miller's credit, most previous cases in which a language issue appeared inconsistent at first glance have turned out to have very solid reasoning behind them (about 99.9% of the time). But nothing is perfect, and nearly everything can be refined just a bit closer to perfection: once upon a time the MC engine used a non-standard order for the items that described the printMargins (they were not L,T,R,B as other rects are defined). This was reported as a bug, and even though it required changes to scripts that had relied on the old order it was promptly changed in the next release, and today the language has one less exception to remember. In this case, we'll either see a change for greater consistency, or gain a deeper understanding of the rules to help us understand why this instance is truly consistent. -- Richard Gaskin Fourth World Media Corporation Developer of WebMerge 2.0: Publish any database on any site ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com Tel: 323-225-3717 AIM: FourthWorldInc _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
