Weirdness Passing Messages

[J. Landman Gay]

Richard Gaskin wrote:
> David Burgun wrote:
> 
>>  From what you say below, I can understand why put x into me *may*  
>> not work, but not why:
>>
>> set the text of me to x
>>
>> doesn't work either?
> 
> 
> Others may disagree, but I consider that a bug and have filed a report 
> on it:
> 
> <http://support.runrev.com/bugdatabase/show_bug.cgi?id=3418>

I agree, there's a problem here. I have now looked at a sample stack 
that David sent me in email.

> 
> If Transcript is to be learnable we must at least expect property 
> settings to be consistent.
> 
> The "set" command must act like the "set" command, and "me" should 
> resolve to the object reference when used in conjunction with "set".

I don't think the problem is with "set". I think it is with the 
interpretation of "me".

> 
> In this case, even if it's an inherited HyperTalk behavior I believe it 
> should be updated to be consistent.  The future holds more newcomers 
> than old HyperTalkers, and I see no benefit to sacrificing a much larger 
> future to adhere to a bad practice used by very few people (if it all) 
> in the past.

There is no problem with HC compatibility; HC acts differently than Rev 
here.

> 
> And there may be no conflict at all in honoring "set" consistently -- 
> how did HyperCard handle such cases?

In HyperCard, you can't use "set the text of" so "set" isn't an issue. 
However, when I made a duplicate stack in HC, and changed the commands 
to "put xxx into me" (for compatibility) HC worked fine. So the problem 
is only in Rev.

> 
> 
>> Also, why in the case where the handler is called from one place it  
>> works but if called from within another Handler  it doesn't!

It isn't clear to me yet, but I suspect it's the way "me" is 
interpreted. "Me" is the object (or contents) of the currently running 
handler, but since the sample stack does a lot of "sends", I believe the 
engine isn't successfully tracking which object is "me". It appears to 
think only the original handler's object is "me", which in a way is true 
because the first object's handler really *is* still running. When you 
specify the long name instead of "me" then the object reference is more 
specific and it works.

This may be due to the fact that, as Richard mentioned, fields on remote 
cards are not initialized; I'm not sure. If that's true, then in this 
case there is no "me" except for the originating object on card 1.

This isn't to say it shouldn't be fixed, only that I can see how it 
would get mucked up. The way the sample scripts are written is fairly 
convoluted; I would never have thought to do the job this way. I suspect 
that is why this problem has never been reported in all these years, 
since as Richard mentioned, it really takes a very specific setup to 
reproduce this problem.

A much better approach would be to move all the handlers into the stack 
script and take advantage of the natural message hierarchy, rather than 
relying on all those "sends".


> 
> This seems related to the ambiguity of "me": sometimes it refers to the 
> object, sometimes to the object's contents.
> 
> I'm not sure if this particular case is a bug or an inherited HyperTalk 
> "feature" -- maybe Jacque knows?

It is not how HC works. HC does what you'd expect.

> If this is not how HyperTalk works I would encourage you to create a bug 
> report for that one as well.



-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com