Crazy script-only stack question

[Geoff Canyon]

Navigator has used buttons on the second (never shown) card for a couple
years now. I'm currently testing a convert to SoS function in Navigator,
the first practical use of which will be to convert Navigator. I'm looking
forward to GitHub, and not having a directory listing like this hiding on
my computer:

Navigator 5.0 alpha 2.zip
gSB latest 4.5.1 Navigator.rev 28.zip
Navigator.rev 27.zip
5.0a1 Navigator.rev 26.zip
Navigator.rev 25.zip
Navigator.rev 24.zip
Navigator.rev 23.zip
Navigator.rev 22.zip
Navigator.rev 21.zip
Navigator.rev 20.zip
etc...

On Tue, Jan 23, 2018 at 10:13 AM, J. Landman Gay via use-livecode <
use-livecode at lists.runrev.com> wrote:

> There was a long and amusing discussion about what to call the object that
> actually holds the behavior script. When behaviors were first implemented,
> only buttons could be used as the container. In some cases it was necessary
> to refer to the container button itself, for example, to get a property.
> Since "me" always refers to the control using the behavior we needed a
> specifier. "This me" was eventually suggested as a joke but no one could
> think of a better term, and it fit very well with existing LC syntax. I
> still smile when I have to use it, which has happened only once when the
> button stored different custom property sets for use on different platforms.
>
> Behaviors in buttons are still supported, which I hope never changes,
> because there are advantages. Script only stacks cannot be debugged using
> remote debugging, which makes developing on mobile devices very difficult.
> Buttons travel with the stack, eliminating sometimes dozens of extra files
> in the app directory, and there's no need to keep the stackfiles updated.
> And you can store a lot more info in a button besides just a script. Your
> Navigator could probably be more compact if you stored behaviors in hidden
> buttons, and you wouldn't have to worry about installation of external
> files.
>
> Script only stacks are very useful for git, but if I'm not using that I
> still prefer buttons. I've used both methods and each has its purpose.
> --
> Jacqueline Landman Gay         |     jacque at hyperactivesw.com
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
>
>
> On January 23, 2018 10:52:04 AM Geoff Canyon via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
> I just checked, and yeah, this me is portable between object scripts and
>> behavior scripts, but it seems highly unlikely that the concept itself
>> would be portable. i.e. it's far more often the case that a reference to
>> me/this me from an object's script *should* be a reference to the control
>> itself, not the behavior, and copy-pasting it into a behavior script would
>> be an error. "the behavior of me" accomplishes the same thing as "this me"
>> in a behavior script, and is far more clear besides.
>>
>> On Tue, Jan 23, 2018 at 8:33 AM, Bob Sneidar via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>> This Me refers to the behavior object itself, not the object using the
>>> behavior. That is so that scripts referring to Me can be ported to a
>>> behavior without modification (I assume) and Me will still refer to the
>>> calling object. I suppose they could have used Real Me or some such
>>> thing.
>>>
>>> I have never actually had a need to refer to the behavior object itself
>>> in
>>> one of it's handlers. The only use case I can imagine is if you wanted to
>>> send or dispatch to call a handler in the behavior, but it's already in
>>> the
>>> front of message heirarchy for the calling object.
>>>
>>> Bob S
>>>
>> _______________________________________________
>> 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
>>
>
>
>
> _______________________________________________
> 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
>