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 < firstname.lastname@example.org> 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 > ____________________________________________________________________ > ambassa...@fourthworld.com http://www.FourthWorld.com > > > _______________________________________________ > use-livecode mailing list > email@example.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > _______________________________________________ use-livecode mailing list firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode