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