Guessing game

[Brian Milby]

cREVGeneral is an example of where recursion would be a problem.  In the
common library there are getProp and setProp handlers that depend on lock
messages.  The handlers intercept the message and in some cases need to
lock messages to get the system property before continuing (so a pass would
not work).

On Thu, Apr 5, 2018 at 5:19 PM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:

> 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>