Yes, for the purposes it was designed for (stopping the triggering of
system messages) the "lock messages" command is very useful.
The problem with getProp and setProp is that those triggers occur in
response to *custom* properties, not system properties.
As originally implemented (and as remains since) if you use libraries or
other components which may lock messages, the effects on getProp and
setProp can be unknowable in advance, and difficult to pin down when
issues occur from scripts that depend on those messages but sometimes
they're not sent.
Mark Waddingham reviewed this a while back and offered the view that
custom property triggers should follow the convention of custom handlers
being immune to "lock messages".
But there's apparently a challenge there with avoiding recursion which
makes it unlikely getProp and setProp will be revised any time soon to
be immune to lockMessages.
If you work in teams sufficiently disciplined and communicative that any
use of "lock messages" is well accounted for with regard to property
triggers, and restrict use of any third-party components to those with
open code that's been carefully scanned for "lock messages" and
"lockMessages", I suppose this anomaly isn't much of an issue.
It wasn't for me: I got bit only once, moved back to getter/setter
accessors, and moved on; problem solved. :)
--
Richard Gaskin
Fourth World Systems
David Bovill wrote:
Yes - thanks for pointing that out. So far I've found the behaviour of
lockmessages to be actually useful rather than an issue with
getprop/setprop - seems well designed to me.
The place where the syntax really shines is with functions calls rather
than commands - dispatch is quite natural for that. Say you want the model
data of a stack "My Project" - the syntax:
put the project_Data of stack "My Project" into pData
is much more elegant and comprehensible than any way to call a function.
this is also nice:
put the project_Data ["pretty colour"] of stack "My Project" into
defaultColour
On 3 April 2018 at 18:05, Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:
David Bovill wrote:
> The use-case I had was to replace send syntax with the more elegant
> set the ... of object to syntax.
While the getProp and setProp handlers would seem to lend themselves to a
lot of useful object binding opportunities, they require caution: they're
treated by the engine as system messages, and as such are not immune to the
effects of lockMessages the way custom handlers are.
Systems depending on getProp and setProp will need to monitor lockMessages
carefully to insure critical triggers are received as expected.
Using getter and setter accessor handlers avoids that concern, with a
stylistic difference that isn't much more verbose:
set the BeautifulColor of cd 1 to "light-grey"
-vs-
dispatch SetBeautifulColor to cd 1 with "light-grey"
It doesn't read as nicely, but given that the trade-off can be
unpredictability I'll take what I can get. :)
And depending on usage context, in many cases the UI event that initiates
a calling chain may be on the card in question, not requiring
out-of-message-path dispatching, making the call simpler than a property
setting:
SetBeautifulColor "light-grey"
For virtual objects like models, accessors can simplify things by not
requiring that they be bound to a physical object which need not otherwise
exist. The name-value-pair programming we enjoy with custom props applies
equally well with any array. But with arrays we can have deeper levels,
and are more easily savable/transportable than an object bound to a stack
file.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
Ambassador at FourthWorld.com http://www.FourthWorld.com
_______________________________________________
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
