The creation of custom properties is incoherent

[Erik Hansen]

this may be incidental, but a
naming convention that uses: 
the uTot of stack (the mainstack of this stack)
the uFlag, the uHeight etc.
for all custom props might help.
(see Richard Gaskin's site).

Erik Hansen

--- "Dr.John R.Vokey" <vokey at uleth.ca> wrote:

> 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
> 
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
>
http://lists.runrev.com/mailman/listinfo/use-revolution
> 


=====
erik at erikhansen.org    http://www.erikhansen.org


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail