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