You old OCDer, you. :-) Since behavior scripts are only referenced in a
"set the behavior" statement, I'm not sure where you'd use an initial flag.
But if I ever need one, I'd use "b" for "behavior". For now I just name
the button with a trailing "behavior" string,, i. e., "scrollBehavior".
We are all odd in our own way, but as long as we're consistently odd it works.
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On July 8, 2016 11:00:39 AM Richard Gaskin <ambassa...@fourthworld.com> wrote:
J. Landman Gay wrote:
I think we're pretty evenly split between "c" and "u". I prefer "c" because
it is, after all, a custom property. Those who migrated from SuperCard
often prefer "u" because over there, I believe, they are called user
properties.
Richard's guide is pretty good and I follow the other conventions but I
can't get used to writing a "u" for something that starts with a "c".
Apparently the team feels the same.
Back in those early days, when I first started noticing the relatively
consistent naming conventions in use among some xTalk programmers that I
later documented in that article, OOP was just coming into vogue and at
the time several authors were commonly use a "c" prefix to denote class
definitions in some language (perhaps I first got it from a Dave Mark
book? Been so long I don't recall).
Although it's been such a long time between my first proposal for
parentScripts discussed with the Allegiant team for SuperCard and the
xTalk world's first implementation in LC a few years ago, I've always
held onto the belief that the feature's value would eventually be
self-evident enough to see it happen in some xTalk or another.
Since parentScripts (or as they're now unfortunately/ambiguously called,
"behaviors") are in effect class definitions, all these years I've been
holding out hope of using "c" as an identifier for those class
definition objects. And indeed, now that we finally have what LC calls
behaviors, I use "c" that way, in the names of the objects holding a
behavior script.
It's an admittedly small benefit, made even smaller by my habit of also
coloring buttons with behavior scripts a bright yellow so they stand out
even more. But sometimes that sort of OCD thing makes me happy.
So while LC's nomenclature may make "c" a more natural-seeming fit for
what it calls "custom properties" for the feature that premiered in the
xTalk world as "user-defined properties" in SuperCard, for my own code
(and Ken's and some others as you've noted) I still use "u" for those,
at long last able to use "c" for the purpose I'd always hoped for. :)
--
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
_______________________________________________
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
