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
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
