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

Mark Waddingham 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]
>     OR
>   update [objectRef] from array [arrayRef]
> where the array would be in the format of the export and the object 
> would
> 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 
obvious).

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 
> of
> the complexity would go away since key existence could be checked 
> directly
> instead of flags for example (on import mainly).  All of the code 
> specific
> to versions < 9 would not be needed.  It would start with the MCObject 
> and
> be needed everywhere else.  The existing import/export code would then 
> need
> 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 
> the
> import could re-create an exact duplicate.  There would need to be a 
> check
> on the ID and altID to ensure a duplicate isn't being created (with
> appropriate/sensible handling of collisions).  The import would be 
> fully
> backwards compatible since if the object key is not present, then it 
> would
> 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 
> this
> interesting too.  A single statement could be used to update multiple
> values/properties/settings of an object at once.  I'm sure there are 
> pretty
> big gotchas on that though since it would likely avoid proper messages 
> from
> 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 
script).

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 
mentioned before).

The reason to do this is that it would give an equivalence between:

   import object from array ...

and

   create tArray["type"]
   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.

Warmest Regards,

Mark.

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




More information about the Use-livecode mailing list