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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
