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
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
