The group command

[Richard Gaskin]

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