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"
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
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.
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription