Feedback request: getProp/setProp and lockMessages

[Richard Gaskin]

There's a discussion in the Engine Contributors Section of the forum in 
which a change has been proposed, and to make sure the benefits of the 
change outweigh any potential issues with backward compatibility I've 
been asked to run it past you folks here:


PROBLEM: LockMessages limits the usefulness of getProp and setProp
------------------------------------------------------------------
With built-in props, behavior changes occur when a property is set 
regardless of the state of lockMessages. Setting the listBehavior of a 
field, for example, will change that field's behavior whether 
lockMessages is true or false.

Custom controls, however, often require custom properties, and unlike 
built-in properties for native objects the change can be suppressed if 
the user changes a property in a custom control while lockMessages is 
true. In some cases this may cause unexpected appearances, and in the 
worst case could conceivably result in data loss with some custom controls.

Also, once we have getProp and setProp for built-in properties, the same 
brittleness becomes introduced for overloaded built-in properties as well.

Because custom controls can be adversely affected by lockMessages, sadly 
I rarely use getProp and setProp, despite how good a fit they are for 
such things in all other respects, opting instead for accessor handlers 
to set those values and trigger those actions, requiring clumsier syntax 
to use.

So to bring custom controls up to par with native controls in terms of 
robustness, some solution needs to be invented so they can be reliable 
and robust independent of whether the scripter needs to block system 
messages.



SOLUTION: Make getProp and setProp immune to lockMessages
---------------------------------------------------------
Mark Waddingham supports the proposed change with this reasoning:

The idea of lockMessages is to stop engine messages from being sent - 
there's a certain mechanism in the engine which all engine originated 
messages use and that will do nothing if lockMessages is true. The 
getProp / setProp messages use the same mechanism but *technically* the 
message does not originate from the engine - it originates from script.

At the moment there are the following ways 'messages' get dispatched:

     direct call (e.g. doMyHandler tParam1 in script).
     send / call / dispatch
     getProp / setProp handlers (invoked via 'the prop of obj')
     engine events (e.g. mouseUp / mouseDown)

Of these only the last two no-op if lockMessages is set. Given that 
send/call/dispatch/direct calls which all originate from script ignore 
lock messages, perhaps getprop / setprop handler invocation should too?

..If it can be agreed that setProp/getProp handlers are in fact *not* 
engine messages (and are more like send / call / dispatch / direct 
calls) then they should ignore the setting of lockMessages thus solving 
the issue without any need to introduce new types of handlers, or 
special cases.

The argument for setProp/getProp messages not being considered to be 
engine messages is pretty simple - the only way they are ever invoked is 
by an explicit line in script:

     get the myCustomProp of <object>

And it is hard to see why that should be treated differently from:

     dispatch function "getMyCustomProp" to <object>



REQUEST: Would this adversely affect your scripts?
--------------------------------------------------
In short, Mark is suggesting that getProp and setProp are essentially 
custom messages, and therefore should be redefined as such, allowing 
them to work regardless of the state of lockMessages.

Personally, I agree with Mark's assessment and feel the benefits far 
outweigh any possible downsides.  In fact, for my own work I can't see 
any downsides at all.

However, when introducing elements that may change backward 
compatibility the team is keenly interesting in soliciting feedback from 
the community to make sure there aren't critical use cases that may have 
been overlooked.

So please take some time to think about this proposed change, and if you 
have a circumstance which would be adversely affected by the change 
describe it here so it can be considered.

If the cost to developers is as low relative to the benefits as I think 
they are this change would likely appear in a new build soon (perhaps 
not the next one but probably not long after).  So please take a moment 
to think this over, and offer your feedback here.

Thanks in advance for your participation in this process -

--
  Richard Gaskin
  Fourth World
  LiveCode training and consulting: http://www.fourthworld.com
  Webzine for LiveCode developers: http://www.LiveCodeJournal.com
  Follow me on Twitter:  http://twitter.com/FourthWorldSys