Object Reference in Variable?

[Richard Gaskin]

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
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com