Get fillGradient props

[J. Landman Gay]

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         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com



On July 8, 2016 11:00:39 AM Richard Gaskin <ambassador at 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
>   ____________________________________________________________________
>   Ambassador at FourthWorld.com                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode