The creation of custom properties is incoherent

[Ken Ray]

On 9/12/04 8:20 PM, "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*.  

Actually, it is quite consistent - local variables are filled with values as
soon as data is assigned to them (unless explicitVariables is set to true).
Until that time, they act as literals. Compare:

  put test  --> puts "test" into the message box

  put 10 into test
  put test  --> puts "10" into the message box

Rev first tries to evaluate a string as a variable to see if it has been
defined. If it has, it substitutes the value for the variable and proceeds
in its evaluation. If it has not been defined, it is treated as a literal
string.

This is why:

  set the test of this stack to true   -- first instance in your example

creates a custom property called "test" and assigns it the value "true", and
why:

  put "fred" into test
  set the test of this stack to true

creates a custom property called "fred" and assigns it the value of true
("test" is found to be a defined variable so its value is substituted in the
string)

> 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.

Really? I'd be very interested to know if this is the case. The reason I say
that is that custom properties are referred to in the same manner as regular
properties, and we don't say:

  set the "visible" of button 1 to true

I would have thought people would be comfortable with unquoted property
names for custom properties.

> 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!

You can also do:

  on mouseUp
    repeat with i = 1 to 5
      do "set the" && ("prop" & i) && "of me to i"
    end repeat
  end mouseUp

although I agree that your first example *should* be able to be made to work
and should not error out, IMHO.
 
Ken Ray
Sons of Thunder Software
Web site: http://www.sonsothunder.com/
Email: kray at sonsothunder.com