Script Only Stack Architecture

[Matt Maier]

I just want to chime in to disagree with the idea that we should leave
useful information out of the Dictionary.

There's no such thing as a document that's too big when we have networks
and search. Even if we're forced to browse and read we can just put the
information in order of importance so that the more trivial stuff is at the
end.

If it takes a while to explain, then it takes a while to explain. If there
are a lot of caveats, then there are a lot of caveats. That sounds like a
good reason to simplify the application, not a good reason to keep secrets.
What feels like a "hefty tome" to someone with decades of experience feels
like a "gold mine" to someone with no experience. A lot of gold is heavy;
that's just how it works.

On Thu, Mar 31, 2016 at 1:41 PM, Richard Gaskin <ambassador at fourthworld.com>
wrote:

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