Guessing game

[Richard Gaskin]

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