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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
