Script Only Stack Architecture

Sannyasin Brahmanathaswami brahma at hindu.org
Thu Mar 31 16:09:50 EDT 2016


I don't think I'm super smart... or over thinking it

I think the idea that you have to open an external behavior stack *before* you open the main stack that has controls which point to it as their parent, is totally unintuitive and when a newbie reads "load, open, put into memory" etc... he/she will always assume this can happen in the preopenstack handler.  even your b) explanation will  throw a newbie

"Load "MyBehaviorStack" into memory without opening it. "

It is or is not open after you query the property? do you really mean:

"You can query a property to open the stack in the background and put its stack script into memory."

a) b) (with explanation above)  c) below + Jacque's explanation could go in the dictionary... I don't think that's over loading it. had that been what I read at Git Hub, we could have avoided several days for lost time.

OTOH, we did get the gold out of it:  your nested behaviors/as-classes tutorial...

So it was all worth it!


For my use case, stack files seems the simplest way to go and most rock solid.

On March 31, 2016 at 9:44:06 AM, Richard Gaskin (ambassador at fourthworld.com<mailto:ambassador at fourthworld.com>) wrote:

Sannyasin Brahmanathaswami wrote:

> ergo: merely opening a script-only stack that is applied as a
> behavior to a control (not global in scope) does *not* place
> into the msg path.

Respectfully, your recipe would be easier to follow without the steps
unrelated to the actions we're exploring (making folders and such - the
folder locations are unrelated to the problem).

Remember guideline #2 in my earlier post:

2. When using behaviors, the object containing the behavior script
must be in memory when anything relying on it is brought into
memory.
<http://lists.runrev.com/pipermail/use-livecode/2016-March/225274.html>

If I'm following your recipe correctly, the field object that uses the
behavior is in a stack that opens and then loads the stack used to
define the behavior.

This means that at the moment the field object is unpacked for use it
contains a reference to a behavior object not yet in memory.

The engine (in its current form; we can expect this to be improved later
as time permits) will only attempt to resolve a behavior once, when the
object dependent on the behavior is brought into memory.

Even if you later open a stack containing the behavior script, by that
time it's too late. The object depending on it has already been
unpacked, the behavior reference already attempted, and having failed it
will not be retried as other stacks are later opened.

For the moment let's forget that in your case the stack file used as a
behavior object is a script-only stack. The storage format doesn't
affect anything at runtime, and may be distracting here. Let's just
focus on the load order:


SIMPLIFIED RECIPE
-----------------
Stack "MyTestStack" has a field, which is assigned stack
"MyBehaviorStack" as its behavior property.

Stack "MyBehaviorStack" is a separate stack file.


POSSIBLE SOLUTIONS
------------------
Options for correct behavior esolution when "MyTestStack" is loaded include:


a) Open "MyBehaviorStack" first.
-----------------------------
In an application this may mean introducing one more stack, which
we could call "MyBootStack", which first opens "MyBehaviorStack"
and then opens "MyTestStack".


b) Load "MyBehaviorStack" into memory without opening it.
------------------------------------------------------
This can be done by accessing a property of "MyBehaviorStack",
such as the stack's name. This still requires "MyBootStack"
to make sure that "MyBehaviorStack" is in memory before
"MyTestStack" is opened, but has the minor convenience of
not being visible to the user and triggers no opening messages.


c) Include "MyBehaviorStack" in the stackFiles prop of "MyTestStack".
-----------------------------------------------------------------
Any stack files specified in the stackFiles property of a stack
are loaded into memory at the same time the stack containing that
list is loaded. In terms of boot sequence it's functionally
similar to having those separate stack files as substacks, but
with the advantage of keeping them separate.


a) and b) conform to Guideline #2 above in an obvious way, explicitly
putting "MyBehaviorStack" into memory before "MyTestStack" will be
opened to need it.

c) works because stack files listed in the stackFiles property are all
loaded with the stack listing them, before behavior resolution takes place.


This seems harder than it is in part because you're super smart and are
just thinking too hard. :)

Relax. Put script-only stuff out of your mind, and just think about the
load order.

Behaviors are among the most powerful things ever introduced in the
xTalk family of languages. I waited literally 20 years for them, since
Allegiant first accepted my proposal for parentScripts but then went
belly-up before they could implement it. Well worth even that wait:
they greatly simplify so many aspects of building complex systems, and
simple systems become simpler.

The load order rule (Guideline #2 above) in LC is a bit funkier than
we'd hope for, but even that's not hard to accommodate once we
understand it.

Pick a, b, or c, to handle the load order, and the world is your oyster.

--
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


More information about the use-livecode mailing list