Developing first on android

[Mark Waddingham]

On 2017-08-18 18:05, Brian Milby via use-livecode wrote:
> What about a non-binary stack file format?  Something XML based and 
> derived
> from the actual in-memory stack object (would need to be integrated 
> with
> the IDE/engine to be really useful though - to allow seamless/native
> import/export).

I think Monte's lcVCS might well be a good starting point for that - 
there's no real need to have engine support as long as we make sure all 
the things you need to know to deconstruct / reconstruct a stackfile are 
accessible from script (which is where the engine support kicks in).

That being said, there is one piece of engine functionality which would 
make lcVCS and similar tools much simpler - the ability to ask the 
engine for a LiveCode array representing the actual persistent state of 
any LiveCode object. If you have an array which contains a faithful 
representation of the persistent state, then you can write serializers / 
deserializers to whatever text (or other!) format you like in LiveCode 
Script (which is a much much better place for such things to be!).

There is a starting point here for this. In order to allow lcVCS to 
support widgets (which can have arbitrary persistent state), we added a 
new form to the 'export' and 'import' commands:

export <widget> to array <arrayVar>
import <widget> from array <arrayVar>

We also added 'is strictly' operators which allow you to detect the 
actual dynamic type of a value, rather than what values it could be:

   put "100" is a number -- true
   put "100" is strictly a number -- false

This allows lcVCS to create a faithful representation (in JSON) of the 
values in LiveCode variables - in particular, in those returned from 
export/import widget.

The reason I mention this is that this ability really is the precursor 
to eliminating the engine's dependence on a bespoke binary stackfile 
format (which is actually a huge problem - for all kinds of reasons) - 
if we had a fully faithful (in the strict mathematical sense!) 
import/export array ability - a stackfile could just become an array 
which has been encoded with any hierarchical data encoding format (of 
which the arrayEncode format is one, JSON is another, BSON is another, 
YAML is another, ...).

It might be that the part of lcVCS which does the JSON mapping might 
well be completely sufficient - perhaps Monte could chime in here to 
comment and remind me of the issues he had / faced with it.

I can recall one significant issue - the properties we set on objects 
(or widgets - lamentably) are not necessarily reflective of the 
persistent state. What I mean by this is that, in some case, you cannot 
directly set one of the internal persistent state variables of an object 
directly by a property - it can only be done by setting a combination, 
or by other actions (I'd need to look through the engine code to remind 
myself where this occurs).

However *that* is fixable - we make sure that there are suitably human 
understandable properties for all objects which ensure you can easily 
import and export them using just those properties. For widgets, it 
comes to down to imposing a simple rule:

Any piece of state which is saved into the state array (on OnSave) 
*must* be accessible by a public property.

This would actually simplify widget creation - as you wouldn't need an 
OnLoad / OnSave handler at all then. It would just be a case of 
serializing the properties which are marked as 'persistent'. This is one 
case where I modelled the engine's behavior, and shouldn't have done - I 
should have ignored how the engine did things and just gone with 'what 
made more sense'!

Anyway, I'd suggest we start looking at lcVCS (in terms of its object 
import/export - not the VC related aspects) and see what issues it has; 
then look at starting to fix those issues in the engine; then look to 
start adding array import/export methods for all LiveCode objects... 
Assuming this is an interesting project someone (not looking at anyone 
in particular ;)) would like to take up...

Warmest Regards,

Mark.

>> Mike Kerner wrote:
>> 
>> > I've been thinking of developing a deconstructor to use with Levure.
>> >  The idea is that you would lay out the objects, but then the
>> > deconstructor would pull all the properties of each object, put them
>> > in a YML, JSON, or other similar file, and then they would be built in
>> > the app by  script, when needed.
>> 
>> That would be handy.  I've considered making one, but the cost/benefit
>> relative to other commitments here has prevented me from diving in. I
>> appreciate your interest in this, and know you'll do a fine job with 
>> it.
>> 
>> While it's understandable that Git can't handle LC's binary files, one 
>> of
>> the strongest benefits of "The xTalk Way" is visual design.
>> 
>> This is why so many of us have written libraries to automatically
>> instantiate mobile-specific controls for us from LC-native objects, 
>> because
>> it lets us enjoy the fluid development workflow that characterizes 
>> xTalks,
>> rather than defining objects by typing long blocks of object 
>> definitions in
>> scripts, which is a very C way of doing things.
>> 
>> Automating use of Git through binary->script decomposers allows 
>> developers
>> the full benefit of the best of both xTalk and lower-level workflows.
>> 
> _______________________________________________
> 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

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