J. Landman Gay wrote:
On 2/20/11 10:37 PM, Richard Gaskin wrote:
dunbarx wrote:
> It is not stable. Scott is correct in that we all agreed that the
> only reliable workaround was to use the templateGroup to advantage.
Sorry, but I missed that meeting: under what circumstances does the
local var "it" not contain the long id of the newly-created group object
when "it" is checked as the very next action following a "create group"
command"?
When you aren't using "create", the "it" variable has no value:
select control 1 and control 2
group
put it
Produces nothing.
True, and I recognize that it's not always practical to use "create" to
create new objects.
I guess the only upside here is that so far it appears as though "it" is
indeed reliable as long as you use "create", and workarounds are only
needed in some cases where you create objects by other means.
It seems to me that at the core of this is the multiple roles "it"
plays: sometimes used for new object references, sometimes used for
returning essential data ("answer file"), and sometimes used for errors,
"it" wears too many hats to be reliable for any of those roles across
all possible circumstances.
Rather than have one variable serve so many very different
circumstances, most OS APIs provide some sort of LastError function to
obtain info about whatever might have gone wrong with the previous
statement.
If LiveCode were to adopt this common convention, "it" would be freed up
for the other sorts of data usages it's used for, while providing us a
more predictable method of obtaining error info.
I just submitted a request for considering a long-term migration to
LastError() as an alternative to overloading "it":
<http://quality.runrev.com/qacenter/show_bug.cgi?id=9408>
Recognizing that this will have significant impact on legacy code, I
suggested there that this be handled like the forthcoming change to the
"char" chunk type: "byte" was delivered many versions ago as a more
reliable token for doing byte operations, so we have many years to
implement any needed changes in our code before "char" is no longer a
synonym.
Similarly, I suggested in that request that LastError() be added soon,
but without changing the behavior of "it" for a few years going forward.
This would leave us all with plenty of time to change our code between
the time LastError is available and when it becomes necessary.
I suspect there would be much resistance to such a pervasive change,
perhaps not the least from the RunRev team themselves.
But I also believe that continuing to overload "it" will only lead to an
ever greater confusion in cases like object creation, and even with
error handling itself, so sooner or later we'll all face the reality
that OS API designers faced when they decided to migrate error handling
to error-specific functions rather than rely on some catch-all for all
sorts of very different uses.
--
Richard Gaskin
Fourth World
LiveCode training and consulting: http://www.fourthworld.com
Webzine for LiveCode developers: http://www.LiveCodeJournal.com
LiveCode Journal blog: http://LiveCodejournal.com/blog.irv
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
