Script Only Stack Architecture

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

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

Perhaps.  Ideally we'd need to user-test that to affirm the assumption. 
It wouldn't have occurred to me, but I've spent too long using xTalks to 
be a reliable gauge of what it takes to learn them (which is why the 
older I get the more ardent I've become about listening carefully to 
people who know nothing about the software; that precious naivety leaves 
so quickly, and is invaluable during that brief moment it still exists).

The one thing everyone agrees on is that the current need to be so aware 
of load order for behavior resolution is undesirable and needs to be 
changed at first opportunity.  Mark Waddingham doesn't much care for it 
any more than you or I do.  I'd be surprised if it isn't resolved (all 
puns intended) by 8.2 if not sooner.

Fortunately we have the convenient stackFiles property to make this a 
bit simpler in the meantime.


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

Whether a stack is "open" if loaded into memory without using an "open" 
or "go" command is perhaps a philosophical question.

Personally I try to use "open" to describe a stack's runtime state only 
in cases where I brought it into RAM with "open" or "go", and the rare 
case of anything else as simply "in 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.

Go for it, but please be brief in Dictionary entries.   This thread is 
as long as it is in part because of a misunderstanding of what "start 
using" does, which may merit mention there but on the other hand if we 
included caveats in every Dictionary entry to cover mistakes I've made 
trying to misapply commands it would be a tome too hefty to read. :)

Rather than enumerate all possible ways do not do something, just focus 
on what you want them to do.


 > OTOH, we did get the gold out of it:  your nested behaviors/as-
 >classes tutorial...
 >
 > So it was all worth it!

Glad that was helpful.   Nested behaviors are da bombdiggety!

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