Developing first on android

[Brian Milby]

If I'm understanding correctly, a capability to export a stack as an array
(with the corresponding import) would get around the issue of the
non-public properties though.  The array would be the intermediate format
that would be used by the engine to construct the stack in memory.  LCS
could be used to serialize into a suitable disk format.  It would mean that
the only way to get a full representation of the object would be to use the
full import if there were properties like you described above (unless I'm
missing something).

I've actually been mulling something along these lines over for the past
few weeks (but was thinking about a direct XML format).  I briefly looked
at the code to save a stack and noticed how it seems pretty straight
forward.  I'll take a look at the code for some of the objects this weekend
and see what I think.  Could be a good opportunity for the community to
contribute a useful new feature.

On Fri, Aug 18, 2017 at 11:56 AM, Mark Waddingham via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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
>
>
> _______________________________________________
> 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
>