Crazy script-only stack question

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Crazy script-only stack question

dunbarx via use-livecode
Is there any reason script-only stacks had to be implemented in the engine?

Is there any reason *not* to implement their equivalent in about five lines
of code in the mainstack of a project? i.e.,

on loadTextStack tFilePath
    put url ("file:/" & tFilePath) into tStackData
    put line 1 of tStackData into tStackName
    create invisible stack tStackName
    set the script of stack tStackName to line 2 to -1 of tStackData
    send "openStack" to stack tStackName
end loadTextStack

This would immediately fix the issue of chained behaviors, and allow for
the incremental implementation of a far richer format for text-based stack
storage, leading to gains in project-definition source control.

Given that Bug 10275 <http://quality.livecode.com/show_bug.cgi?id=10275> is
over five years and several versions old, am I barking up a tree with this,
or making sense?

with no clue,

Geoff
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
[hidden email]> wrote:

> Is there any reason script-only stacks had to be implemented in the engine?
>

It is nice that you can store the scripts for controls in a UI stack
alongside of the ui stack file. You just set the stackfiles property of the
UI stack and then opening the UI stack opens up all of the behavior stacks
that the UI stack requires without any extra effort on the part of the
developer.


> Is there any reason *not* to implement their equivalent in about five lines
> of code in the mainstack of a project? i.e.,


For some cases dispatching a message can be useful. I don't think I would
use `openStack`, however, as that doesn't describe the event that is
occurring. You are just loading the stack into memory. A script only stack
can create a UI and may expect the `openStack` message to be dispatched at
the proper time and in the proper sequence relative to other messages that
are sent when actually opening a stack.

I wouldn't load all of my script only stacks that way, however. I use
script only stacks in a variety of ways. For libraryStacks they already get
a `libraryStack` message. If I'm using them as behaviors for controls in a
UI stack then they are automatically loaded by the engine for me as
described above. In the majority of cases that doesn't require any extra
work. In the Levure framework you can specify that a stack file will be use
specifically as a behavior. In the case Levure will dispatch a
`LoadBehavior` message to the stack and it can assign itself a behavior.

My preference is for the ability to set a script only stack behavior in the
script only stack itself.

--
Trevor DeVore
ScreenSteps
www.screensteps.com
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
Not barking up the wrong tree at all, with multi-stack apps very much in the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_) not having and a RCS for the binary stacks themselves is a nuisance. But your 5 liner doesn't solve that either.

But how does creating a stack and setting it's script to a text file different from adding a stack to your framework and then setting the behavior of that stack to the text only script?  

Or put another way, what advantage would it have over the behavior of the stack?  And since your newly created stack has no controls, those would all need to be created by script and this is exactly what LiveCode provides: WSIWG layout environment (albeit needs a lot of work to get to 2018 standards )

A case can be made for treating the binary stacks as a "view" Typically there is a split in the team between design and code. This is also happening universally where designers are doing UI/UX prototypes in InVision Or Zeplin.. (no code)  and push these over to the code team.

We have such stacks in the SivaSivaApp. where there is almost no code in the stack at all. We use "the target" …in the text only behavior stacks… this is working pretty well as once the eye candy and UX is locked in, we are not touching that too much, if anyone is, it's usually just one person, so pulling and pushing the binary from GIT is not that big a deal… conflict wise… of course if some others on the team *do* want to touch the UI, then it gets messy

BR

On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via use-livecode" <[hidden email] on behalf of [hidden email]> wrote:

    Is there any reason script-only stacks had to be implemented in the engine?
   
    Is there any reason *not* to implement their equivalent in about five lines
    of code in the mainstack of a project? i.e.,
   
    on loadTextStack tFilePath
        put url ("file:/" & tFilePath) into tStackData
        put line 1 of tStackData into tStackName
        create invisible stack tStackName
        set the script of stack tStackName to line 2 to -1 of tStackData
        send "openStack" to stack tStackName
    end loadTextStack
   
    This would immediately fix the issue of chained behaviors, and allow for
    the incremental implementation of a far richer format for text-based stack
    storage, leading to gains in project-definition source control.
   
    Given that Bug 10275 <http://quality.livecode.com/show_bug.cgi?id=10275> is
    over five years and several versions old, am I barking up a tree with this,
    or making sense?
   
    with no clue,
   
    Geoff

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
We are starting to get a bit afield, but as long as we are, the issues with
the layout editor bring us to the same place as the issues with the script
editor:  Why exert so much effort on the editor instead of writing plugins
for third-party OSS editors, that have a much larger user base and
developers who are actively working on them (and designers developing
interface elements and themes)?

On Mon, Jan 22, 2018 at 3:56 PM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
>
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
>
> Or put another way, what advantage would it have over the behavior of the
> stack?  And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
>
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code)  and push these over to the code team.
>
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
>
> BR
>
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode" <[hidden email] on behalf of
> [hidden email]> wrote:
>
>     Is there any reason script-only stacks had to be implemented in the
> engine?
>
>     Is there any reason *not* to implement their equivalent in about five
> lines
>     of code in the mainstack of a project? i.e.,
>
>     on loadTextStack tFilePath
>         put url ("file:/" & tFilePath) into tStackData
>         put line 1 of tStackData into tStackName
>         create invisible stack tStackName
>         set the script of stack tStackName to line 2 to -1 of tStackData
>         send "openStack" to stack tStackName
>     end loadTextStack
>
>     This would immediately fix the issue of chained behaviors, and allow
> for
>     the incremental implementation of a far richer format for text-based
> stack
>     storage, leading to gains in project-definition source control.
>
>     Given that Bug 10275 <http://quality.livecode.com/
> show_bug.cgi?id=10275> is
>     over five years and several versions old, am I barking up a tree with
> this,
>     or making sense?
>
>     with no clue,
>
>     Geoff
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
I agree that having the ability to use stacks (script-only in particular)
for behaviors is nice -- it lets developers easily put all their code under
source control. But the implementation is flawed, as we've discussed,
because it doesn't support (native, transparent) chaining of behaviors, and
so is a feature-deficient replacement for button behaviors.

In looking at the bug for this -- which is a year and a half old -- I
thought of the idea that app layout could also be under version control if
it, too, had text-based alternative. There's a bug for (roughly) that --
and it is over five years old. So what I'm suggesting is that it seems
unlikely that either of these issues will be fixed in the engine anytime
soon, and further that it doesn't necessarily have to be an engine change
that addresses it.

The code library to make this happen would be almost trivial to write an
MVP for. A simple format (I'd suggest JSON, but newline support seems to be
an issue) would allow starting with a really basic definition, just enough
to support stacks with scripts and properties, which would get us the
equivalent of script-only stacks with chained behaviors. Beyond that it
would quickly be possible to include cards, groups, and controls, with many
(most?) properties, in external files, and voila, source control over the
interface for many projects.

I'm probably under-thinking the complexity, and overthinking the
possibility/need, but I definitely want a standardized way of handling
chained behaviors in source control, and I'd hate to wait another year and
a half to get that one thing.

And: yeah, openstack is a bad idea for the initialization message. It would
be much better to use a custom message -- behaviorStack?

gc

On Mon, Jan 22, 2018 at 12:47 PM, Trevor DeVore via use-livecode <
[hidden email]> wrote:

> On Mon, Jan 22, 2018 at 2:20 PM, Geoff Canyon via use-livecode <
> [hidden email]> wrote:
>
> > Is there any reason script-only stacks had to be implemented in the
> engine?
> >
>
> It is nice that you can store the scripts for controls in a UI stack
> alongside of the ui stack file. You just set the stackfiles property of the
> UI stack and then opening the UI stack opens up all of the behavior stacks
> that the UI stack requires without any extra effort on the part of the
> developer.
>
>
> > Is there any reason *not* to implement their equivalent in about five
> lines
> > of code in the mainstack of a project? i.e.,
>
>
> For some cases dispatching a message can be useful. I don't think I would
> use `openStack`, however, as that doesn't describe the event that is
> occurring. You are just loading the stack into memory. A script only stack
> can create a UI and may expect the `openStack` message to be dispatched at
> the proper time and in the proper sequence relative to other messages that
> are sent when actually opening a stack.
>
> I wouldn't load all of my script only stacks that way, however. I use
> script only stacks in a variety of ways. For libraryStacks they already get
> a `libraryStack` message. If I'm using them as behaviors for controls in a
> UI stack then they are automatically loaded by the engine for me as
> described above. In the majority of cases that doesn't require any extra
> work. In the Levure framework you can specify that a stack file will be use
> specifically as a behavior. In the case Levure will dispatch a
> `LoadBehavior` message to the stack and it can assign itself a behavior.
>
> My preference is for the ability to set a script only stack behavior in the
> script only stack itself.
>
> --
> Trevor DeVore
> ScreenSteps
> www.screensteps.com
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
Yeah, the five-liner is intended only as a way of implementing script-only
stacks with behavior chaining in code rather than the engine (since that
doesn't seem forthcoming. It seem many people are doing something very like
this, at a basic level I'm just proposing that standardizing would be
useful. But the next step would be to support something more robust than
just "line 2 through -1 is the script of the stack". It wouldn't take much
to be able to put much more of a project into source control. But I agree
that there is far more need for the already-available source control of
scripts.

On Mon, Jan 22, 2018 at 12:56 PM, Sannyasin Brahmanathaswami via
use-livecode <[hidden email]> wrote:

> Not barking up the wrong tree at all, with multi-stack apps very much in
> the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> not having and a RCS for the binary stacks themselves is a nuisance. But
> your 5 liner doesn't solve that either.
>
> But how does creating a stack and setting it's script to a text file
> different from adding a stack to your framework and then setting the
> behavior of that stack to the text only script?
>
> Or put another way, what advantage would it have over the behavior of the
> stack?  And since your newly created stack has no controls, those would all
> need to be created by script and this is exactly what LiveCode provides:
> WSIWG layout environment (albeit needs a lot of work to get to 2018
> standards )
>
> A case can be made for treating the binary stacks as a "view" Typically
> there is a split in the team between design and code. This is also
> happening universally where designers are doing UI/UX prototypes in
> InVision Or Zeplin.. (no code)  and push these over to the code team.
>
> We have such stacks in the SivaSivaApp. where there is almost no code in
> the stack at all. We use "the target" …in the text only behavior stacks…
> this is working pretty well as once the eye candy and UX is locked in, we
> are not touching that too much, if anyone is, it's usually just one person,
> so pulling and pushing the binary from GIT is not that big a deal… conflict
> wise… of course if some others on the team *do* want to touch the UI, then
> it gets messy
>
> BR
>
> On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> use-livecode" <[hidden email] on behalf of
> [hidden email]> wrote:
>
>     Is there any reason script-only stacks had to be implemented in the
> engine?
>
>     Is there any reason *not* to implement their equivalent in about five
> lines
>     of code in the mainstack of a project? i.e.,
>
>     on loadTextStack tFilePath
>         put url ("file:/" & tFilePath) into tStackData
>         put line 1 of tStackData into tStackName
>         create invisible stack tStackName
>         set the script of stack tStackName to line 2 to -1 of tStackData
>         send "openStack" to stack tStackName
>     end loadTextStack
>
>     This would immediately fix the issue of chained behaviors, and allow
> for
>     the incremental implementation of a far richer format for text-based
> stack
>     storage, leading to gains in project-definition source control.
>
>     Given that Bug 10275 <http://quality.livecode.com/
> show_bug.cgi?id=10275> is
>     over five years and several versions old, am I barking up a tree with
> this,
>     or making sense?
>
>     with no clue,
>
>     Geoff
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
I don't think age of the QR means anything except someone was ahead of
their time.  If the mothership suddenly says "aha" then we get "aha"

On Mon, Jan 22, 2018 at 6:30 PM, Geoff Canyon via use-livecode <
[hidden email]> wrote:

> Yeah, the five-liner is intended only as a way of implementing script-only
> stacks with behavior chaining in code rather than the engine (since that
> doesn't seem forthcoming. It seem many people are doing something very like
> this, at a basic level I'm just proposing that standardizing would be
> useful. But the next step would be to support something more robust than
> just "line 2 through -1 is the script of the stack". It wouldn't take much
> to be able to put much more of a project into source control. But I agree
> that there is far more need for the already-available source control of
> scripts.
>
> On Mon, Jan 22, 2018 at 12:56 PM, Sannyasin Brahmanathaswami via
> use-livecode <[hidden email]> wrote:
>
> > Not barking up the wrong tree at all, with multi-stack apps very much in
> > the wind…a subject of interest indeed. Agreed with Igor, (ala bug 10275_)
> > not having and a RCS for the binary stacks themselves is a nuisance. But
> > your 5 liner doesn't solve that either.
> >
> > But how does creating a stack and setting it's script to a text file
> > different from adding a stack to your framework and then setting the
> > behavior of that stack to the text only script?
> >
> > Or put another way, what advantage would it have over the behavior of the
> > stack?  And since your newly created stack has no controls, those would
> all
> > need to be created by script and this is exactly what LiveCode provides:
> > WSIWG layout environment (albeit needs a lot of work to get to 2018
> > standards )
> >
> > A case can be made for treating the binary stacks as a "view" Typically
> > there is a split in the team between design and code. This is also
> > happening universally where designers are doing UI/UX prototypes in
> > InVision Or Zeplin.. (no code)  and push these over to the code team.
> >
> > We have such stacks in the SivaSivaApp. where there is almost no code in
> > the stack at all. We use "the target" …in the text only behavior stacks…
> > this is working pretty well as once the eye candy and UX is locked in, we
> > are not touching that too much, if anyone is, it's usually just one
> person,
> > so pulling and pushing the binary from GIT is not that big a deal…
> conflict
> > wise… of course if some others on the team *do* want to touch the UI,
> then
> > it gets messy
> >
> > BR
> >
> > On 1/22/18, 10:21 AM, "use-livecode on behalf of Geoff Canyon via
> > use-livecode" <[hidden email] on behalf of
> > [hidden email]> wrote:
> >
> >     Is there any reason script-only stacks had to be implemented in the
> > engine?
> >
> >     Is there any reason *not* to implement their equivalent in about five
> > lines
> >     of code in the mainstack of a project? i.e.,
> >
> >     on loadTextStack tFilePath
> >         put url ("file:/" & tFilePath) into tStackData
> >         put line 1 of tStackData into tStackName
> >         create invisible stack tStackName
> >         set the script of stack tStackName to line 2 to -1 of tStackData
> >         send "openStack" to stack tStackName
> >     end loadTextStack
> >
> >     This would immediately fix the issue of chained behaviors, and allow
> > for
> >     the incremental implementation of a far richer format for text-based
> > stack
> >     storage, leading to gains in project-definition source control.
> >
> >     Given that Bug 10275 <http://quality.livecode.com/
> > show_bug.cgi?id=10275> is
> >     over five years and several versions old, am I barking up a tree with
> > this,
> >     or making sense?
> >
> >     with no clue,
> >
> >     Geoff
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> > subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
> >
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
On 2018-01-22 21:20, Geoff Canyon via use-livecode wrote:
> Is there any reason script-only stacks had to be implemented in the
> engine?

Yes - otherwise direct stack references or 'stackfiles' indirected
references wouldn't work. You'd need a binary 'launcher' stack for each
script, which would then be a bane for version control (which would have
defeated their purpose).

The reason script-only stacks came about was to solve a very real
problem we had internally. Whilst we were working on 7, we were still
evolving 6 as well. Every couple of months we needed to update the s/b
scripts for iOS (due to SDK updates), and that was becoming a real PITA
as it was too easy to lose changes in the binary stackfiles causing
bugs, regressions and lots of headaches.

Now, as it turned out, the core iOS s/b scripts were just a script in a
stack - i.e. a pure library - so I added a new serialization of a stack
object which was just the text of the script and moved the library to
the engine repository. That way, all changes merged generally merged
cleanly - we only had to make the changes in the earliest version and
then merge upwards.

An important thing to remember about script-only-stacks is that,
morally, they are script objects - nothing more. The fact they are
embodied as a stack object is an implementation detail (one which fits
in well with the existing notion of library stacks - i.e. start using).
Implementing them as a restricted storage form for stacks meant that no
further infrastructure internally was needed.

i.e. There is a very good reason why the first line of SOS's is 'script
<name>' and not 'stack <name>' :)

I do see general version control of UI elements as a very much a
separate problem (and probably one far better done in LCS, rather than
the engine - see Levure!).

In terms of behaviors, then they are another example of script objects -
indeed, the object the script is attached to has little to do with any
semantics of behaviors (although we did add 'this me', to allow resource
resolution relative to the behavior object - I'd suggest not using it
for anything else other than that ;)).

Now since the behavior of an object could be considered to be a property
of the script of the object, and not the object itself (behaviors have
no interaction at all with anything other than script concerns) it is
entirely reasonable to propose to allow the behavior reference to be
specified in the format of the SOS.

I'd propose the following:

   script <script-name> with behavior <behavior-name>

Where <behavior-name> is resolved as a stack reference.

The reason to restrict this to a stack reference here is that anything
other than stack references do not work well with dVCS due to the need
to use an id reference, and if you are using control scripts as
behaviors you probably aren't going to get very far with dVCS usage
anyway, which kinda negates the point of using a SOS (it is also simpler
and cleaner, both externally and internally).

> Given that Bug 10275
> <http://quality.livecode.com/show_bug.cgi?id=10275> is
> over five years and several versions old, am I barking up a tree with
> this,
> or making sense?

There have been several attempts to do dVCS on arbitrary LiveCode stacks
- but it isn't really possible in any sane way which preserves the kind
of interaction with dVCS's which everyone expects (in particular
services such as Bitbucket and Github).

Levure type models (and what we have been doing with the IDE - moving
things to script only stacks) is a much better solution for those sorts
of tools.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
On Tue, Jan 23, 2018 at 1:49 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2018-01-22 21:20, Geoff Canyon via use-livecode wrote:
>
>> Is there any reason script-only stacks had to be implemented in the
>> engine?
>>
>
> Yes - otherwise direct stack references or 'stackfiles' indirected
> references wouldn't work. You'd need a binary 'launcher' stack for each
> script, which would then be a bane for version control (which would have
> defeated their purpose).
>

​Yep, I get that I was proposing a hack, non-100% solution.​ Hence "Crazy"
in the subject line ;-)


>
> In terms of behaviors, then they are another example of script objects -
> indeed, the object the script is attached to has little to do with any
> semantics of behaviors (although we did add 'this me', to allow resource
> resolution relative to the behavior object - I'd suggest not using it for
> anything else other than that ;)).
>

​This actually raises another point (and I'm sure this is a discussion that
happened without me several years ago, but as long as we're here) is there
a reason to use "this me" which seems terribly awkward, over "the behavior
of me" which is to my ear far more straightforward​ (it didn't require any
additional code or syntax) if a bit more verbose?


> I'd propose the following:
>
>   script <script-name> with behavior <behavior-name>
>
> Where <behavior-name> is resolved as a stack reference.
>

​Sure, that sounds perfect​.

gc
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
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


> On Jan 23, 2018, at 08:21 , Geoff Canyon via use-livecode <[hidden email]> wrote:
>
> <snip> is there a reason to use "this me" which seems terribly awkward, over "the behavior of me" which is to my ear far more straightforward​ (it didn't require any additional code or syntax) if a bit more verbose?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
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 <
[hidden email]> 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
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
It isn't This Me that is portable (Mark indicated it shouldn't be used anywhere but in a behavior script itself if I recall) but it is simple Me that is portable. Me will always refer to the object USING a behavior (or not as the case may be) and not the behavior itself.

Bob S


> On Jan 23, 2018, at 08:49 , Geoff Canyon via use-livecode <[hidden email]> 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.


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
Geoff Canyon wrote:
 > "the behavior of me" accomplishes the same thing as "this me"
 > in a behavior script, and is far more clear besides.

Agreed, and there was a looooong thread about alternatives back when
"this me" was proposed, but it's been around so long now that I doubt
it's going away.

I feel similarly about "behavior" vs "parentScript".  The former is so
generic that one needs to be very mindful of context when using it, to
avoid confusion with other behaviors in the more common sense.
ParentScript is geekier, but intentionally so: it's an invented work to
describe a very specific thing, and as such avoids ambiguity while being
more inherently communicative.

But much like "destroyStack" for a non-destructive behavior, or allowing
property syntax for some function calls (but not others), or
"playLoudness" for what the world calls "soundVolume", these are among
the charms of our dialect that keep consultants employed. ;)

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote:
> ​This actually raises another point (and I'm sure this is a discussion
> that
> happened without me several years ago, but as long as we're here) is
> there
> a reason to use "this me" which seems terribly awkward, over "the
> behavior
> of me" which is to my ear far more straightforward​ (it didn't require
> any
> additional code or syntax) if a bit more verbose?

There's a longish thread on the engine forum about this...

The 'behavior of me' works fine as long as you aren't using a chained
behavior - in the latter case, it would only give you the behavior
object directly attached to 'me' (i.e. the object the behavior's are
acting on).

The need to actually get the object a behavior's script resides in is
really quite a rare operation (the only reason I think it is useful at
all in the context of script-only stacks being used for behaviors is for
resolving paths to resources relative to the behavior script file) so in
the end I plumped for something simple to add which wasn't going to
cause any difficulties in implementation or potential ambiguities - its
strangeness helps reinforce the fact 'are you sure you need to do this'
as well :)

In actual fact, I wonder whether it is really needed at all for
behaviors expressed as script only stacks - you can use 'the filename of
stack <name of behavior>' - which is more verbose but means you can
avoid 'this me'. (Given that if you change the name of a behavior, any
references to it break, you are forced to choose your behavior names
wisely - hence why we use reverse-dns notation in the IDE).

Pondering slightly, if we codify the notion of a script object (i.e.
something which is just a script), then perhaps we could have:

   - this object (me): the object currently executing

   - this script (this me): the script currently executing

Perhaps something to consider in the future (I've not spent any time
considering whether 'this script' might have a more useful
connotation!).

>> I'd propose the following:
>>
>>   script <script-name> with behavior <behavior-name>
>>
>> Where <behavior-name> is resolved as a stack reference.
>>
>
> ​Sure, that sounds perfect​.

I did a patch for this whilst having coffee this morning:

    https://github.com/livecode/livecode/pull/6290

It garnered some discussion internally - mainly whether the idea of a
'loadStack' message would be better. I think it was decided that
'loadStack' (i.e. a message sent after a stack is loaded, but before
opened - something which happens whenever you reference a stack via a
chunk without a go/open verb) was an orthogonal thing (and a fair bit
more difficult to implement!).

Still needs some tests and generally checking around the idea - but as
it stands at the moment it seems like a reasonable addition.

Warmest Regards,

Mark.

--
Mark Waddingham ~ [hidden email] ~ http://www.livecode.com/
LiveCode: Everyone can create apps

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
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         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com



On January 23, 2018 10:52:04 AM Geoff Canyon via use-livecode
<[hidden email]> 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 <
> [hidden email]> 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
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode



_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
On Tue, Jan 23, 2018 at 9:42 AM, Mark Waddingham via use-livecode <
[hidden email]> wrote:

> On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote:
>
>> ​This actually raises another point (and I'm sure this is a discussion
>> that
>> happened without me several years ago, but as long as we're here) is there
>> a reason to use "this me" which seems terribly awkward, over "the behavior
>> of me" which is to my ear far more straightforward​ (it didn't require any
>> additional code or syntax) if a bit more verbose?
>>
>
> There's a longish thread on the engine forum about this...
>
> The 'behavior of me' works fine as long as you aren't using a chained
> behavior - in the latter case, it would only give you the behavior object
> directly attached to 'me' (i.e. the object the behavior's are acting on).
>

​Yeah, agreed, in this circumstance "the behavior of me" would be lacking.


>
> The need to actually get the object a behavior's script resides in is
> really quite a rare operation (the only reason I think it is useful at all
> in the context of script-only stacks being used for behaviors is for
> resolving paths to resources relative to the behavior script file) so in
> the end I plumped for something simple to add which wasn't going to cause
> any difficulties in implementation or potential ambiguities - its
> strangeness helps reinforce the fact 'are you sure you need to do this' as
> well :)
>

​Class variables are a fairly defined thing in the OO world, and this seems
equivalent to those.


>
> In actual fact, I wonder whether it is really needed at all for behaviors
> expressed as script only stacks - you can use 'the filename of stack <name
> of behavior>' - which is more verbose but means you can avoid 'this me'.
> (Given that if you change the name of a behavior, any references to it
> break, you are forced to choose your behavior names wisely - hence why we
> use reverse-dns notation in the IDE).
>
> Pondering slightly, if we codify the notion of a script object (i.e.
> something which is just a script), then perhaps we could have:
>
>   - this object (me): the object currently executing
>
>   - this script (this me): the script currently executing
>
> Perhaps something to consider in the future (I've not spent any time
> considering whether 'this script' might have a more useful connotation!).
>
> I'd propose the following:
>>>
>>>   script <script-name> with behavior <behavior-name>
>>>
>>> Where <behavior-name> is resolved as a stack reference.
>>>
>>>
>> ​Sure, that sounds perfect​.
>>
>
> I did a patch for this whilst having coffee this morning:
>
>    https://github.com/livecode/livecode/pull/6290
>
> It garnered some discussion internally - mainly whether the idea of a
> 'loadStack' message would be better. I think it was decided that
> 'loadStack' (i.e. a message sent after a stack is loaded, but before opened
> - something which happens whenever you reference a stack via a chunk
> without a go/open verb) was an orthogonal thing (and a fair bit more
> difficult to implement!).
>
> Still needs some tests and generally checking around the idea - but as it
> stands at the moment it seems like a reasonable addition.
>
> ​Woot!​
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
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 <
[hidden email]> 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         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
>
>
>
> On January 23, 2018 10:52:04 AM Geoff Canyon via use-livecode <
> [hidden email]> 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 <
>> [hidden email]> 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
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
In reply to this post by dunbarx via use-livecode
@JLG I thought with "breaktpoint" you could debug SOS behaviors

On Tue, Jan 23, 2018 at 1:21 PM, Geoff Canyon via use-livecode <
[hidden email]> wrote:

> On Tue, Jan 23, 2018 at 9:42 AM, Mark Waddingham via use-livecode <
> [hidden email]> wrote:
>
> > On 2018-01-23 17:21, Geoff Canyon via use-livecode wrote:
> >
> >> ​This actually raises another point (and I'm sure this is a discussion
> >> that
> >> happened without me several years ago, but as long as we're here) is
> there
> >> a reason to use "this me" which seems terribly awkward, over "the
> behavior
> >> of me" which is to my ear far more straightforward​ (it didn't require
> any
> >> additional code or syntax) if a bit more verbose?
> >>
> >
> > There's a longish thread on the engine forum about this...
> >
> > The 'behavior of me' works fine as long as you aren't using a chained
> > behavior - in the latter case, it would only give you the behavior object
> > directly attached to 'me' (i.e. the object the behavior's are acting on).
> >
>
> ​Yeah, agreed, in this circumstance "the behavior of me" would be lacking.
> ​
>
> >
> > The need to actually get the object a behavior's script resides in is
> > really quite a rare operation (the only reason I think it is useful at
> all
> > in the context of script-only stacks being used for behaviors is for
> > resolving paths to resources relative to the behavior script file) so in
> > the end I plumped for something simple to add which wasn't going to cause
> > any difficulties in implementation or potential ambiguities - its
> > strangeness helps reinforce the fact 'are you sure you need to do this'
> as
> > well :)
> >
>
> ​Class variables are a fairly defined thing in the OO world, and this seems
> equivalent to those.
> ​
>
> >
> > In actual fact, I wonder whether it is really needed at all for behaviors
> > expressed as script only stacks - you can use 'the filename of stack
> <name
> > of behavior>' - which is more verbose but means you can avoid 'this me'.
> > (Given that if you change the name of a behavior, any references to it
> > break, you are forced to choose your behavior names wisely - hence why we
> > use reverse-dns notation in the IDE).
> >
> > Pondering slightly, if we codify the notion of a script object (i.e.
> > something which is just a script), then perhaps we could have:
> >
> >   - this object (me): the object currently executing
> >
> >   - this script (this me): the script currently executing
> >
> > Perhaps something to consider in the future (I've not spent any time
> > considering whether 'this script' might have a more useful connotation!).
> >
> > I'd propose the following:
> >>>
> >>>   script <script-name> with behavior <behavior-name>
> >>>
> >>> Where <behavior-name> is resolved as a stack reference.
> >>>
> >>>
> >> ​Sure, that sounds perfect​.
> >>
> >
> > I did a patch for this whilst having coffee this morning:
> >
> >    https://github.com/livecode/livecode/pull/6290
> >
> > It garnered some discussion internally - mainly whether the idea of a
> > 'loadStack' message would be better. I think it was decided that
> > 'loadStack' (i.e. a message sent after a stack is loaded, but before
> opened
> > - something which happens whenever you reference a stack via a chunk
> > without a go/open verb) was an orthogonal thing (and a fair bit more
> > difficult to implement!).
> >
> > Still needs some tests and generally checking around the idea - but as it
> > stands at the moment it seems like a reasonable addition.
> >
> > ​Woot!​
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:
> @JLG I thought with "breaktpoint" you could debug SOS behaviors

I haven't actually tried that yet. It would be more difficult to avoid
debugging when you just want to run the stack normally but would be
better than nothing. I suppose you'd need to remember to remove all the
breakpoint commands from the SOS files at some point. Have you tried it yet?

--
Jacqueline Landman Gay         |     [hidden email]
HyperActive Software           |     http://www.hyperactivesw.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Crazy script-only stack question

dunbarx via use-livecode
I have not.  I broke the remote debugger and haven't played with it in a
month or more.  What I was thinking of doing was having a breakpoint
wrapper that only fires if I have a variable or property set, e.g. a global
called "debug", or having my "execute" debug method, that gives me an
answer box, lets me type in any LC statement I want, and then "do"es it
fire a breakpoint

On Tue, Jan 23, 2018 at 4:15 PM, J. Landman Gay via use-livecode <
[hidden email]> wrote:

> On 1/23/18 12:27 PM, Mike Kerner via use-livecode wrote:
>
>> @JLG I thought with "breaktpoint" you could debug SOS behaviors
>>
>
> I haven't actually tried that yet. It would be more difficult to avoid
> debugging when you just want to run the stack normally but would be better
> than nothing. I suppose you'd need to remember to remove all the breakpoint
> commands from the SOS files at some point. Have you tried it yet?
>
> --
> Jacqueline Landman Gay         |     [hidden email]
> HyperActive Software           |     http://www.hyperactivesw.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12