Is this sort of thing a bug?

[Richard Gaskin]

David Bovill wrote:

>> 2009/9/17 Richard Gaskin <ambassador at fourthworld.com>
>>
>> Given this, you should be able to simply refer to the long name of the
>> substack without needing to explicitly include its mainstack:
> 
> Yes - the point is that the following give a result that is not only
> unexpected but plain wrong (go on - try it and see):
>
>> put the name of stack "revLibrary" into stackObject
>> put the long name of stack "revSaving" of stackObject = the long name of
>> stack "revLibrary"  -- believe it or not this is true!

Yep, verified.

If I may suggest, the bug report title might give one the impression 
that the issue is specific to those rev stacks, and given the complexity 
of the Rev IDE such anomalies can be related to a great many things such 
as the way the IDE sometimes renames some of its parts on the fly.

I verified the issue with a simpler stack, with a mainstack named "a" 
and a substack named "b", using this script:

on mouseUp
   put the name of stack "a" into tMainStack
   put the long name of stack "b" of tMainStack into buggyResult
   answer warning "Bug" && buggyResult
end mouseUp

It's probably just because I've been using this family of languages too 
long that I've come to expect oddities in every xTalk when it comes to 
concatenating object descriptors from mixed parts.  HC, SC, and others 
have each had various issues with resolving compound object references, 
often with slight variations between each of these dialects with what 
will work and what won't.

Of all of the xTalks I've worked with, I've found Rev to be the most 
forgiving.  Still has some warts, but overall I can throw a wider range 
of things at it and get a good result than I've been able to with just 
about anything else I've used.  But it seems there's still work to do 
with these resolutions.

Interestingly, a slight modification to the original script to put only 
the short name of the mainstack into a var and then include the object 
type in the script works well:

on mouseUp
   put the short name of stack "a" into tMainStack
   put the long name of stack "b" of stack tMainStack into tResult
   answer "Good: " && tResult
end mouseUp

Looking for a more general principle driving this in Rev's interpreter, 
I tested card references as the base of a compound descriptor, and it 
seems to work well:

on mouseUp
   put the long id of cd 1 of stack "b" into tCard
   put the long id of btn 1 of tCard
end mouseUp

It also works with group references once I put my test buttons into a group:

on mouseUp
   put the long id of grp 1 of stack "b" into tGrp
   put the long id of btn 1 of tGrp
end mouseUp

So the issue seems limited to mainstack references in compound 
expressions in which the object type is part of the variable.  While 
annoying and inconsistent, the bug has a fairly limited scope and is 
easily worked around with a simpler and faster line-liner:

   put the long name of stack "b" into tResult

You can also use:

   put the long id of stack "b" into tResult

Both return the same value.*


> In my MVC libraries handlers frequently pass around the objects they acts
> on. So early on I put object references into a variable:
> 
> put the long id of the target into targetObject
> 
> and then pass the variable "targetObject" around. As such a handler that get
> passed a reference to a stack in a variable should be confident that it does
> what is expected. In my case it did not and added an object to the main
> stack and not the substack because of the above bug.

I often do the same (with the only difference being that I'm a lazy 
typist so I tend to use the var name "tObj" <g>).

Using "the long if" works with all objects, and in my experience this 
easiest-to-obtain form consistently provides reliable results.

The tricky part of all xTalks is the rarer task of needing to obtain an 
object reference with a compound expression.  From time to time it may 
be needed, but fortunately not often.  When it is, with Rev at least we 
can mix and match portions of expressions with a flexibility I've not 
found in any other xTalk dialect, with the sole exception of mainstacks 
which will require a little more care.  A gotcha sure enough, but 
luckily one which will affect few scripts.


> As a passionate advocate for the language and its robustness - maybe a few a
> votes here <http://quality.runrev.com/qacenter/show_bug.cgi?id=8277> would
> get this annoyance fixed :)

It does appear to be a bug, and I've added one of my votes there (which 
at the moment is the only vote - why is it most folks don't vote for 
their own bugs?).  I've also added my notes above to the report to help 
the team hone in on the root cause.

Any opportunity to remove exceptions in the language will aid adoption, 
which benefits RunRev even more than us.  Thank you for filing the report.



* Now HERE's an anomaly:  if you ask for "the long id" of a stack, you 
get a value which makes the ID of a stack appear to be synonymous with 
its long name, e.g.:

   stack "b" of stack "/Users/rg/Desktop/a.rev"

But if you ask for "the short id" of a stack, you get an arbitrary 
integer assigned dynamically at runtime which appears to change from 
session to session, e.g.:

   1007

Since "the short id" of a stack is close to meaningless, having "the 
long id" of a stack return a value that can be used as an absolute 
reference is helpful, so we can write our scripts to refer to any object 
using "get the long id of <whatever>" and it'll always work regardless 
of object type.

But I can't understand why stacks have an integer value for "the short 
id"; it's both inconsistent with its long id, and inconsistent with the 
IDs of every other object which are a fixed part of the object record.

Since stack names in memory must be unique, it might make more sense to 
have "the short id" of a stack return its short name.  Maybe Dr. Raney 
was anticipating a future in which stack names did not necessarily have 
to be unique; can't say for sure.

I haven't filed this as a bug because I'm uncertain what exactly would 
be best here.  Consistency is the goal of course, but stack integer IDs 
can't be unique across sessions unless they adopt some complicated thing 
like a UID for stacks, and using the short name for the short id would 
conflict with another request I've submitted to move beyond the 
unique-stack-name-in-memory limitation:
<http://quality.runrev.com/qacenter/show_bug.cgi?id=1061>

What would be the ideal solution to make short and long IDs of stacks 
most consistent with the rest of the language?

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com