How to get the number of lines of a fld referenced by long ID in a variable.

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

 > But that it would be nice not be "stuck" with only finding out the
 > properties of the variable as a variable.
 >
 > i.e. pField is a variable with 1 line…
 >
 > but  to be able to address the properties of the object referred to by
 > a variable containing the long ID of an object/
 >
 > How do we do that?

By addressing properties using property syntax.

A field is an object; the text of a field is a property of the object.

If you adopt a habit of referring to properties using property syntax 
the ambiguity goes away, e.g.:

    get line 2 of the text of pField

How did we get to this "sometimes" rule, where referring to an object 
sometimes refers to the object itself and other times refers to one 
specific property of the object, its text?

Thank the mother tongue, HyperTalk.  For reasons not entirely unsound 
for an authoring system, they recognized that a field's text property is 
the most commonly accessed property.  So to provide a certain level of 
syntactic simplicity they allowed us to use an object reference in cases 
where what we really mean is the value of that one property of the object:

    put field 1 + field 2 into field 3

..is certainly more fun to write than:

   set the text of field 3 to the text of field 1 + the text of field 2

Seems so natural to use the shorter form, and indeed that first line 
above is included in my introductory lesson when I teach this family of 
languages.

But that syntactic simplicity comes at a cost.  Everything in an 
imperfect universe involves trade-offs; nothing is a magic pony.  Here 
the trade-off for syntactic simplicity is cognitive load down the road 
from the ambiguity introduced by this implicit property access.

It causes confusion for even folks who've been scripting in these 
languages for decades, evidenced in this thread. :)

So very soon after the seductive quality of referring to a field's text 
property by using a reference to the field object has the learner 
hooked, I introduce the text property, along with other properties, and 
suggest using property syntax where practical, esp. when the object 
reference is in a variable*.

Yes, the rules that distinguish when an object reference will actually 
refer to the object and when an object reference will implicitly refer 
to the value of one specific property of the object are knowable, likely 
documented, and ultimately teachable.

But all these years later it still causes confusion now and then, so I 
try to avoid the ambiguity with a habit of referring to the text 
property using the same syntax I'm expected to use for any other 
property, at least when the object reference is in a variable.

When using a hard-wired object reference it rarely matters at all.  But 
the moment I'm referring to an object in a variable, I either need to 
remain mindful of the implications of this language ambiguity or simply 
stick to the pattern of referring to object properties using property 
syntax.



* Insanely OCD tidbit:  Most of the time when I store an object 
reference in a variable I do so using the object's long ID.  It's 
absolute and unambiguous, and doing that consistently means I don't need 
to think as much.

To remind myself that I'm using the long ID, I've adopted a habit of 
using the variable name tObj.  I use it a lot, and it's short so it's 
easy to type.

This distinguishes it from those exceptional cases where I might use 
just the short name of an object, like a field name, where I'll use 
something like tFieldName.  With that, years later I can readily see 
that it's not how I most commonly do things, and describes the form the 
variable contains within the variable name.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com