Array literals and script only stack initialization (was Re: Developing first on android)

[Monte Goulding]

> On 22 Aug 2017, at 2:58 pm, Brian Milby via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> 
> I think there may be a strategy to avoid a large part of the ID collision issue.    Wouldn't need full on UUIDs, just assign a range to each developer working the UI.    Upon import they could even be collapsed down to the natural order range or left as is.    It would require the temporary setting of the stack ID and being able to revert (thinking the alt ID may be useful here).    Dev A could start at 5001, Dev B at 6001, etc.    Main stack would remain with the 1001 series.    The idea would be that in the preopenstack handler that a check would be made for the dev environment and the developer.    The alt ID would be set for the stack.    When new objects are created, the engine would use the alt ID if set.    There would be a corresponding call to clear the stack alt ID to go back to the normal series (say for the primary developer) and probably also go in the close stack handler.    Custom properties could be used to track where each developer was in their sequence.

The lcVCS approach was to assign everything a UUID and then translate ID properties (icon,pattern,behavior etc) to the UUIDs and then translate them back to the new UUIDs when the stack is being re-created. It works well enough but you do end up seeing UUIDs in diffs. Probably what would be better would be to require unique long names (at least for objects that need this translation) and translate to those. That way you would see something readable.

> 
> Although the diffs may not be useful for coordinated development, don't you think they would be useful to compare snapshots?    Using github, it would show a bunch of lines where data just changed which wouldn't be all that useful but being able to see the new objects which should be easily identifiable should be useful.

Hehe… I think I’m perhaps a little jaded because I ended up creating a bit of a monster with lcVCS largely because of the UUIDs and the fact that it is a directory structure rather than a single file. Yes it would definitely be very helpful if we can get it right.

JSON is also not very good for diffs unless you have a not very strict parser which allows comma at the end of the last element of an array or object.

So… ideally we would have YAML <-> Array that is at least as fast as mergJSON and then a single file format that shmoozes the array before saving to remove unnecessary stuff. Working out what is unnecessary is fun too… I ended up with a plugin system in lcVCS so you could write a little bit of code for a custom control like a DataGrid to decide which custom properties to kill on save.

It’s probably not necessary to start from scratch here. Disregarding the YAML bit for a second the other bits only require relatively small changes to lcVCS. Well dropping UUIDs would be a bit of work but not too bad. When array export is possible then that’s just a matter of swapping out use of the properties property for array export/import.

Cheers

Monte