Mystery with arrays (lost key)

[Ben Rubinstein]

on 15/4/02 1:45 PM, Robert Brenstein at rjb at rz.uni-potsdam.de wrote:

> (Ben wrote)
>> I totally agree (with both you and Scott).  But note that currently in
>> MetaTalk there is one place where you _can't_ use a quoted literal, namely
>> in custom properties.
.. ...
> 
> Ben, I am not sure why you want to use quotes here for custom
> property names. Those names become part of the xTalk syntax once
> defined, so there is no need to quote them. You do not use quotes
> when calling your handlers or functions, do you?
> 
>> doesn't; and nor does this:
>> 
>> on mouseUp
>> put 23 into sourcefile
>> answer the sourcefile of me
>> end mouseUp
>> 
>> I think this is a bug in the parser, or a hole in the syntax.
> 
> Here you define a local variable called "sourcefile" creating a
> namespace conflict so do speak. I believe that local var name simply
> takes priority so you are effectively asking for "answer the 23 of
> me" in the second like and such a property (23) does not exist.


Robert,

I understand what is happening here.  I just think it's wrong.

As you say, in the line
>> answer the sourcefile of me
'sourcefile' is being interpreted as a variable, and the value of the
variable is being used as the property name.  My point is that in that
situation, one should be able instead to use a quoted literal, to ensure
that the correct property name is accessed.

By contrast, try this in a button

    on mouseUp
        put 23 into script
        put the script of me
    end mouseUp

In this case, 'script' is parsed as a literal, so the text that appears is
the script of the button.  Indeed, if you do this:

    on mouseUp
        put 23 into script
        put script && the script of me
    end mouseUp

The message is 23, followed by the script.  So there is an inconsistency
here; script is working fine as a variable, but the parser is taking it as a
literal when used in the context of a property.

The question is, in the expression:
    the <propertyname> of <object>

what is <propertyname>?  Is it
    a literal
    a variable
    a container
    a source of value

It's not any source of value: you can't compile a script that uses a
function to define the required property name, eg
    put the someProp() of me

It's not any container: you can compile this script
    put the fld 1 of me

and it 'works' - it accesses some property, and you can also assign values
to that property - but the text of fld 1 happens to be "script", you won't
get the script of the object from the above expression.  (It's actually very
odd - you can even assign values to this property, and retrieve them, but
the property doesn't turn up in the customProperties of the object).

And it's not even any variable, because as we note certain variable names,
which appear to be legal - at least they're not reserved words - are parsed
as literals - an example being "script".

So I think this expression
    the <propertyname> of <object>

has a very anomalous syntax.  One way of dealing with this would be to make
it entirely literal; so that

    put the myscript of me

has the same status as

    put the script of me

In each cases, the reference would be to a property named "myscript" or
"script", regardless of any use of that property name as a variable
elsewhere.

The disadvantage of this would be that one would lose the facility to decide
at run-time what property is being accessed, eg
    put "highbid" into whichBid
    get the whichBid of me

would no longer work.  But there are several ways round this, either using
"do", or using the properties or customProperties of the object.

An alternative approach would be to allow the name of the property to be any
expression, so that eg
    get the whichbid of me
    get the chooseBid() of me
    get the (hilitedText of btn "propchoice") of me
    get the "highbid" of me

would all be legal.  This would leave us still with the original problem, of
unquoted literals being a potential source of errors for the unwary; but at
least there is now a way for the more wary to be cautious, by carefully
quoting all their property names just as they do other literals.  This is
where we came in; you quoted Scott Raney

>>> and Scott strongly recommends to always quote literals. It is
>>> definitely a cleaner way to code and eliminates any ambiguities.

and I agreed, and pointed out that there was a situation here in which it
was not possible to code so as to avoid ambiguities.

 
  Ben Rubinstein               |  Email: benr_mc at cogapp.com
  Cognitive Applications Ltd   |  Phone: +44 (0)1273-821600
  http://www.cogapp.com        |  Fax  : +44 (0)1273-728866