Array literals and script only stack initialization (was Re: Developing first on android)
mark at livecode.com
Mon Aug 21 13:17:39 EDT 2017
On 2017-08-21 18:09, Brian Milby via use-livecode wrote:
> What about something like
> import into [objectRef] from array [arrayRef]
> update [objectRef] from array [arrayRef]
> where the array would be in the format of the export and the object
> be an existing object.
There are a few options - we have import/export array for widget, which
naturally extends to any object type; so I'd be inclined to start there.
That being said, in the first instance, it would be best to focus on
just the core properties - rather than the hierarchical structure which
perhaps means a variant of 'the properties' might be better (and more
In any case, there's a fair bit of internal work to do before it can be
exposed at the syntax level, so this doesn't have to be decided now.
> I've been looking at the code and think that it would be
> straightforward to
> take the save/load code and change it over to creating an array. Some
> the complexity would go away since key existence could be checked
> instead of flags for example (on import mainly). All of the code
> to versions < 9 would not be needed. It would start with the MCObject
> be needed everywhere else. The existing import/export code would then
> to call appropriate handlers to take care of the object info if the key
> existed ([$object] as a suggestion).
There's some work already done along these lines - I'll dig out the
branch in due course. It was an attempt to abstract the internal
structure a bit (using the currently-unused 'Record Type' which has long
been languishing in libfoundation) - but work stopped on it when we
reached a dead end with the dVCS 'stack dir' idea - based on ideas Monte
developed in lcVCS.
It might be a bit overkill for what we actually need though - as
widget's already have a general form - and so its only the engine
controls in C++ which need to be augmented with the ability; so once
done, it isn't going to need more controls needing it.
> If the full specification of the object is in the export array, then
> import could re-create an exact duplicate. There would need to be a
> on the ID and altID to ensure a duplicate isn't being created (with
> appropriate/sensible handling of collisions). The import would be
> backwards compatible since if the object key is not present, then it
> just work like it did before.
Yes - we should export the id, and if the id does not exist then honor
its setting in import. If it does exist, we can either ignore, or throw
an error; forcing the code to delete the id from the array before
importing and have the engine assign one.
> The suggestions about support for inline arrays would actually make
> interesting too. A single statement could be used to update multiple
> values/properties/settings of an object at once. I'm sure there are
> big gotchas on that though since it would likely avoid proper messages
> being dispatched (or the update could dispatch messages as updates
> performed or collect the messages that should be sent and dispatch them
> sequentially after all updates were completed to avoid duplicates). I
> haven't gotten that far in research yet, so not sure.
Yes - there is a nice synergy here - particularly if we go for a
property based mechanism (for existing controls at least) - although I'm
still not 100% sure what would 'look best' here.
I don't think there are any unpleasant 'gotchas' here with regards
messages. The engine tends not to send any messages when properties are
set (there are a couple of exceptions); and it certainly doesn't if it
is loading / saving - so, particularly for import/export there isn't a
problem. *Maybe* if we went down the update via a modified properties
property then we might need to consider it (although, I can only think
of the menuHistory and friends properties which do send a changed
message off the top of my head as a result of a property setting by
One thing though, it is always nice to have equivalences in terms of one
feature being implemented via another means either for speed or for
ergonomic reasons. If we were to go down the road and do this partly for
the 'being able to set object state in a loadStack' type arrangement
then we probably do want to vet the engine objects to make sure all
internal properties can be reflected one-to-one in actual public
properties; and nominate that set as being the 'core' properties (as I
The reason to do this is that it would give an equivalence between:
import object from array ...
set the prop1 to tArray[prop1]
set the prop2 to tArray[prop2]
From memory, one of the issues (which Monte patched the properties
property to deal with) was that the order you set properties in matters;
ideally it wouldn't - as long as you only set the core properties. (i.e.
rect and not the individual parts or pairings there-of).
Having a set of properties for each object (should it be possible) which
act like that is beneficial for general use too - it means that you
don't get hard to trace bugs in code due to mis-ordering mutations of
internally interelated properties.
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
More information about the Use-livecode