Weirdness Passing Messages

Richard Gaskin ambassador at fourthworld.com
Thu Mar 23 09:16:59 EST 2006


David Burgun understandably panicked:
> Is this a Bug? If so it a *REALLY* fundamental one! The only way I  
> can thing to get around this problem 100% is to add a function:
> 
> function PutDataIntoMe theLongName,theData
>    do "put theData into " & theLongName
> end PutDataIntoMe
> 
> and use this anytime I want to put data into "me". However, will I  
> need a getter too? 

Many posts expressing much concern and anguish over this.  I understand. 
  I've been there myself, and later learned to lead others through these 
dark woods.  Indeed, madness is to be found here, but beneath the 
madness is a grain of solid ground, and with a little background and 
much practice you'll understand the Zen of "me" to the point that it'll 
become second nature, and you will have long forgetten how much pain and 
confusion it once caused you -- until the next person encounters it and 
you hear their screams. ;)

Let's see if we can shed some light on a dark token:


There is a long-standing ambiguity in xTalks which has resulted in 
confusion and hair-pulling back to HyperCard 1.0:

In most cases, referencing a property of an object returns its value, 
and referencing the object itself returns a reference to itself (such as 
a long ID).

So you would expect that to get the text of a field you would say:

    get the text of me

...and to get its long ID you would say:

    get me

But alas it isn't so.

In order to support the convenience of saying "get field 1" as a way of 
obtaining its contents instead of "get the text of field 1", the 
language has become littered with ambiguity in other contexts as well, 
such as "me".

This prioritizing of convenience over clarity shows up all over the 
place, with things like "me" sometimes referencing to the object and at 
other times referring to its contents.

Check this out:

1. Make a field
2. Set its name to "Test"
3. Type "This is a test" into it
4. Set its lockText to true
5. Put this script in it:

      on mouseUp
          put the target &cr& the long id of the target &cr \
            & me &cr& the long ID of me
      end mouseUp

You'll get a result that looks like this:

      field "Test"
      field id 1003 of card id 1002 of stack "mystack.mc"
      This is a test.
      field id 1003 of card id 1002 of stack "mystack.mc"

It's interesting to note that line 1, the target, contains only the name 
of the object, not the long ID.  If you had two or more objects with the 
same name then using "the target" would fail, no?

Only sometimes.

If you use "the target" while the current script is running, then even 
though the engine tells you "the target" is only the name it behaves as 
though it's using the long ID, only working on the true target.

But if instead you obtain "the target" and store that value for later 
use, if you have two or more objects with the same name you may only be 
able to refer to the lowest-numbered one.   In such a case you'll want 
to get "the long id of the target" instead.


The folks at RunRev Ltd. could remove this ambiguity by requiring 
everyone to access the text property of an object to get its contents, 
leaving things like "me" and "target" for unambiguous object references 
only.

But given HyperTalk's long history, even though it may be a bad habit 
it's a long-established one, and folks would storm the castle walls with 
pitchforks and torches.  I expect to be flamed as a heretic for even 
questioning this.  :)

So for consistency with ambiguities introduced decades ago in HyperCard, 
RunRev has us living in a world of "sometimes", where sometimes a token 
does one thing and sometimes something else.

Given the mental gymnastics I've seen folks go through with this since I 
first started teach xTalks back in '88, I believe that a *formal* study 
of this would show that unambiguously asking people to access properties 
for contents would actually be easier to learn than the current 
ambiguous rules of "sometimes".  But we are where we are, and it's too 
late to turn back now so we just need to find coping mechanisms for it.

In your case, as noted above we find that asking for the long ID of 
either the target or me returns something more akin to what we might expect.

I haven't recreated your setup here, but it I'll be that incorporating 
"the long ID of me" will help.  The one consistency in all of this is 
that no matter what madness either "the target" or "me" produce by 
themselves, when used in conjunction with "the long ID of" you get an 
unambiguous, usable reference.

Let us know if it doesn't solve it for you and we can explore this further.

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com



More information about the Use-livecode mailing list