Crazy script-only stack question

[Mark Waddingham]

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 ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps