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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
