Object Reference in Variable?

[Eric Chatonet]

Bonsoir Richard,

As I said in a previous post, it seems that you *must* require or set  
a property.
In your example you don't get or set a property.
See the quote below.

Le 26 sept. 08 à 11:28, Eric Chatonet a écrit :

> Bonjour Scott,
>
> The rule is rather simple when working with long IDs or long names:
> You *must* require a property :-)
> <number of lines of> is not strictly a property but <number of  
> lines of the text of> is because <text> is a property but <lines>  
> is just a keyword.

Le 26 sept. 08 à 17:18, Richard Gaskin a écrit :

> Scott Rossi wrote:
>
>> Recently, Richard Gaskin wrote:
>>> The only one I can think of offhand is "value", which executes at  
>>> about
>>> the same speed as "do":
>>
>>>     put the long id of field 1 into tField
>>>     put the number of lines of value(tField)
>> I would say the benefit of this is being able to avoid writing out
>> complicated do statements.  Nice.
>> But, while something like this works:
>>   put the number of lines of value(tField)
>> Rev refuses to compile this:
>>   delete line 2 of value(tField)
>> Error reads: Commands: missing ','
>> Any idea why?
>
> First, let me chime in with the others who suggest putting the long  
> id of the field into a variable, and using property settings to  
> access it.  FWIW I find that simple and consistent, and generally  
> faster than using the value function (which can't precompile its  
> operation, so it runs with similar speed to "send" or "do",  
> measurably slower than compilable expressions).
>
> IMNSHO, the issue here is the ambiguous syntax HyperCard  
> introduced, which Rev attempts to follow faithfully.  While it's  
> convenient to be able to refer to a field's contents by referring  
> to the field, it sometimes raises questions about which you're  
> going to get.
>
> I'm not advocating that we ditch it, or even implying it's  
> necessarily A Bad Thing, just noting that the intention of  
> providing usability in syntax sometimes comes at the cost of  
> learnability.  Ambiguity is the devil's playground. :)
>
> Experimenting with how the compiler handles that expression, I also  
> find that this won't even compile:
>
>   delete line 2 of the text of tField
>
> We're using a property specifier, so why not?
>
> It seems the "get" and "set" commands for properties are the  
> unambiguous ones, and attempting to use chunk expressions with  
> other commands (such as "delete") cause them to operate on the  
> string which is the object reference, rather than the contents of  
> the referenced object.
>
> So you could write instead:
>
>   get the text of tField
>   delete line 2 of it
>   set the text of tField to it
>
>
> To force the compiler to understand that a particular var is an  
> object reference and not a string, we might consider the  
> possibility of allowing an optional type specifier for the  
> variable, a la:
>
>   put the long id of fld 1 into tField as object
>
> That would tell the compiler to always treat tField as an object  
> reference, and never attempt string operations on it.
>
> It does rather change the flavor of the language to introduce  
> types, however, so I'm not convinced it's an optimal solution.
>
> For the moment I'd just do the three-line alternative and move on....
>
> -- 
>  Richard Gaskin
>  Managing Editor, revJournal



Best regards from Paris,
Eric Chatonet.
----------------------------------------------------------------
Plugins and tutorials for Revolution: http://www.sosmartsoftware.com/
Email: eric.chatonet at sosmartsoftware.com/
----------------------------------------------------------------