The creation of custom properties is incoherent
Dr.John R.Vokey
vokey at uleth.ca
Sun Sep 12 21:20:51 EDT 2004
As many of you who use custom properties are no doubt aware, the
following script will produce two custom properties, "test" and "fred",
both set to values of true:
on test
set the test of this stack to true
put "fred" into test
set the test of this stack to true
end test
So, the same script line results in a different result depending on
what came earlier (and globally) in the execution of the stack---a
potential source of almost impossible to track down bugs (well, at
least in my experience). The problem, in my estimation, is that the
first use of the statement is incoherent. As the custom property
"test" has yet to be created, the evaluation of the statement should
fail *because test has no value (yet), unlike the second use of the
statement*. For consistency with the rest of transcript, the first use
(and all other *literal* uses) of the custom property label) should be
quoted or literals, as in: set the "test" of this stack to true (or set
the "te"&"st" of this stack to true, which, of course, *doesn't*
work!). Indeed, virtually every newbie to the use of custom properties
in my experience does exactly that (i.e., assumes that as a literal is
meant, a literal should be used), leading to an error. The second use
is the above script is fine because it is referring either to a
built-in property or to a previously defined custom property whose name
is the value of test. It shouldn't create a new custom property if the
first two possibilities are false.
Furthermore, with the current scheme, one can't do the following:
repeat with i=1 to 5 -- create and set 5 custom properties
set the ("prop"&i) of this stack to i
end repeat
rather one has to resort to:
repeat with i=1 to 5 -- create and set 5 custom properties
put ("prop"&i) into x -- assume x is a new variable name
set the x of this stack to i
end repeat
which is fine, I guess (not really!), unless a property named "x"
already exists!
I don't know what to recommend at this point, but it really is a bug
waiting to bite the unwary. Unfortunately, unlike unquoted button and
field names, which can be rendered consistent and bug-potential free by
the scripter simply by quoting all such names, no such option is
available here.
--
John R. Vokey, PhD
Professor
B.E.R.G. - Behaviour and Evolution Research Group
Micro-Cognition Laboratory
Department of Psychology & Neuroscience
University of Lethbridge
Lethbridge, Alberta T1K 3M4
CANADA
More information about the use-livecode
mailing list