valueDiff for arrays?

[Mark Waddingham]

On 2018-08-05 01:14, Mark Wieder via use-livecode wrote:
> I do realize that. But now that we've opened that can of worms I don't
> think we can just go on ignoring it. And the difference between LC
> script-only stacks and C source files is that you don't get to
> distribute a single compiled object in LC... you end up with a
> mainstack and several text files to distribute, and they need to stay
> together and in the same relative position. It's messy.

Yes - however, as @Brian already pointed out in another message which 
distracted me in terms of a technical point of performance rather than 
the more important' high-level point he made...

>> Perhaps 'Show IDE Stacks in lists' (or whatever it is called) has 
>> become far far too blunt an instrument...
> 
> What I was thinking.
>> For example, the PB could offer a new 'top-level' - which is project. 
>> A project being defined by a set of stacks which share a common name 
>> prefix...
> 
> Well, when the PB was first proposed, that's where I thought this was 
> heading.

Yes - 'projects' are a concept which LiveCode needs - although like lots 
of things its a case of 'when' rather than 'if' (even if the 'when' has 
been and still is measured in rather long timecales!).

> One thing I'd like, since you're asking (place this in the 'watch what
> you ask for' category) is to be able to use script-only stacks as
> substacks. That way I could edit them with a text editor and still
> work with only a single unified object. And the PB would hide the
> component stacks within the mainstack until I chose to examine them,
> the same way that substacks now work. Obviously there are script-only
> stacks that would not need to be substacks, but that's no different
> from the way stacks and substacks work now.

I think modifications to the PB and a stricter naming convention for 
stacks could solve most of the problems which do exist here.

After all it doesn't matter if (in memory) all stacks are in a 'flat' 
list (its up to the engine to optimize lookup) really - what matter is 
the view of them which is presented in the IDE - which is almost purely 
a PB concern.

The other side of this, is what Brian hinted at - when building for 
distribution script-only stacks which are essentially 'children' of some 
component should be built into a single stack with substacks.

This is essentially what scriptification and descriptification do: we 
have code for this in the repository... For example, there is an 
embedded UI stack in the engine which deals with licensing (the one 
which really does anything is in the livecode-private - which you all 
never see as that's the commercial side of the code). The environment 
stack (whether public or private) exists as a collection of script-only 
stacks and a single binary stack which holds the UI in the github 
repository, and when building the engine those collection of files get 
turned into a single mainstack.

This could be done for all the IDE components which are composed in this 
way at the point we build the distribution - it would cut down the 
number of mainstacks considerably, and again perhaps mean 'show LiveCode 
UI elements' actually does the same as it did before things started to 
be scriptified.

The other place this could come to bear is making the S/B (or some 
variant there-of) not only work to produce an application, but also a 
'component/extension' - i.e. a distributable 'compiled' (in some sense) 
form of a collection of script only stacks which were much more easily 
distributable.

The only thing we would lose by using this kind of process on the IDE 
would be the easy ability to 'monkey-hack' the IDE - although not 
significantly - it would just be slightly harder to pull out the changes 
to submit as a PR if you wanted too...

However, that being said - we then just add a way you could just pull 
the IDE repository and have it use an engine from a pre-installed 
distribution.

Internally we tend to edit the IDE from engines built from the engine 
repository - there's various redirection logic in the IDE and engine, so 
that when a 'build-from-source' engine is run, it looks to see if it is 
a github checkout, and if so loads and runs the IDE from the IDE 
submodule checkout.

So upshot - in reality - we have most of the code and mechanisms already 
to at least get a long way to the ideal (which is a much more 
structured, built-in component architecture), it is 'just' a case of 
plumbing it in in some of the ways outlined above. Admittedly, not a 
small project, but certainly not one which would needed to be started 
from ground-zero.

> And btw, thanks for your input on this list. On a Saturday even. Much
> appreciated.

Hehe - well it is a working day for me today, and tomorrow and the next 
week - I'm currently in Dallas, Texas, for FileMaker DevCon.

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps