On 2015-10-11 08:11, Monte Goulding wrote:
On 11 Oct 2015, at 11:36 am, Peter Haworth <p...@lcsql.com> wrote:
Thanks Monte. Maybe I should file a QCC report or have you already
done so?
No I haven’t reported it. I got the impression from the discussion
that it was never intended to support the properties so it wouldn’t
happen. I’m about to propose (on the engine forum) a refactor of the
properties property (which I’ll do if they want me to) that will
essentially make the properties property self maintaining rather than
the current situation which means the list of properties for an object
type needs to be maintained manually. This wasn’t possible before the
refactor and there’s still a few issues like identifying which synonym
of a property is the one to use in the properties array and which
properties should be in the array. The end result will mean the
properties of a widget will be kind + the standard properties for a
control + the standard properties for an object.
I don't think we have ever had the intention not to update the
properties property to make it work for widgets - we just haven't done
so yet.
Part of the reason for this is that 'the properties' property is quite
ill-posed. As it stands it is essentially 'the properties needed to
recreate the object' (after the work Monte did on it a couple of years
ago); however that concept is difficult as it actually requires
hard-coded rules in it to ensure that when you set 'the properties' the
properties are set in the correct order.
Widgets complicate matters somewhat. We make no requirement that the
state a widget must preserve to recreate itself be directly related to
the properties you actually set (this is actually also true of existing
engine controls - hence why there is a need for 'hardcoded' rules in the
properties property implementation).
Now, I'm not saying this situation is ideal, there are various things we
could do in the future to make widgets easier to write if they follow
the rule that 'there should be a set of persistent properties which
don't overlap and fully faithfully allow recreation of the object' (for
widgets that claim to be this, they wouldn't need an OnSave / OnLoad
handler as the engine could synthesise one).
However, that doesn't change the fact that currently engine controls
don't follow that rule and I'd be loathe to put a restriction on all
widgets in that fashion as I cannot forsee the widgets people might wish
to write.
Basically there is a bit distinction between:
1) The data you need to recreate an object (this is what lcVCS needs).
2) The information you need to provide good introspection on created
objects (this is what the IDE / inspectors etc. need).
Right now, I'd be incredibly dubious if a single 'properties' property
could be made to handle both these uses - the lengthy thread a couple of
years ago on this precise topic made that absolutely clear.
Moreover, we have worked quite hard in the IDE to provide a mechanism
for (2) - it is what the new property inspector is based on - i.e. APIs
for returning information and data about objects in the environment.
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
