getProp/setProp immune to lockMessages?

[FourthWorld]

I recall discussions in which a few of us, including Mark Waddingham, expressed a desire for getProp and setProp to become more robust by making them immune to lockMessages.

Given the unanimity with this proposal, and the other changes in LC 8, it would seem perhaps this version would be a good time to implement that, no?

[livecodeali]

This would be more than a little convenient for various IDE things we have on the go at the moment too. Was this an offline conversation or is there a thread somewhere? It would be good to think out any potential pitfalls.

[FourthWorld]

Thanks for chiming in, Ali.

I managed to turn up the original discussion (in retrospect I probably should have continued this there rather than open a new topic):
http://forums.livecode.com/viewtopic.ph ... 048#p90679

Here's the RQCC request for it:
http://quality.runrev.com/show_bug.cgi?id=226

Mark's argument is summarized by his opening statement there:

Here's a thought (which I'm sure is not a new one!) - 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.

I agree with his assessment, and feel it would make getProp/setProp so much more useful. Right now I generally avoid them, because as long as some other script may prevent them from trigger they're not reliable. Glad to hear this would be useful for IDE things too - very useful for me (and Trevor, and Monte, and many others).

[LCMark]

@FourthWorld: Indeed, one should also heed the final comment on that thread:

Anyway, my musings above essentially distill down to this - it would appear that the only reason lock messages 'should' affect setProp/getProp is so that you can avoid the recursion problem. However, the reason this is needed is because the engine is not currently 'clever' enough to check for a situation where a setProp handler is being called recursively unless it is within the setProp handler itself. Thus, judging by the discussion here and on the list, if we make the setProp/getProp logic check the whole call stack for a recursive invocation then I don't see there being any problem with the change. The only obstacle is finding an efficient way to check the call-stack for a prior invocation of such a handler against the same object.

Key part highlighted in bold

[FourthWorld]

What's needed to make that happen? Is there anything in the LiveCode Builder architecture that would simplify that?

[LCMark]

@FourthWorld: A bright idea

The problem is that it is not an operation which 'fails early' on success. Meaning that the fast case is one where recursion is detected - if there is no recursion you have to look at each entry in the call-stack. (Thus meaning a naive implementation would cause a linear time operation to have to occur at the point of a setProp / getProp *and* the engine to be able to easily snoop back over the entire call stack).

Of course, looking back at the original thread I did notice that I wasn't entirely comfortable with the explicit recursion-check that even the current setProp mechanism has (it just only checks the caller) as it smacks of 'unclean semantics' from a conceptual point of view. I'd be all for removing the recursion check entirely... However, as noted on that other thread there is a use-case for using lock/unlock messages around a setProp so you can directly control when it is called - given that this use-case is exhibited directly in the dictionary then we have to assume that is a pattern whilst, if not common, will definitely be out in the wild.

So the current situation is this:

The engine has a very fast recursion check currently in place in setProp (getProp) invocations which means directly within a setProp (getProp) handler invoking the same setProp (getProp) on the same object will cause a message not to be sent and direct access to the backing internal custom prop array to occur.

There is a pattern which has been espoused by the dictionary forever which says that you must use lock/unlock messages around setProp (getProp) invocations in order to have direct access to the custom property backing store rather than go through a message (and to stop infinite recurse).

We could let setProp (getProp) ignore lock messages, but without the recursion check it breaks all existing cases which use the previously suggested pattern (and breaks them in the worse possible way - you get code which enters a tight infinite loop, which before would have worked fine).

Implementing the recursion check that would be needed to ensure that removing the effect of lock messages from setProp (getProp) had minimal effect on existing code (assuming the assumptions I made in the other thread are actually valid!) is not entirely obvious without causing a potentially significant performance penalty on invocation of setProp (getProp) handlers, or at least some subset of invocations of setProp (getProp) handlers.

[FourthWorld]

I was about to get dismayed until I read your other thread, which I'll link to here so others can see the proposal on the table to make this (and more) happen:
http://forums.livecode.com/viewtopic.php?f=66&t=23490

[LCMark]

Well, I don't like to dismay you @FourthWorld.

The 'bright idea' here is realizing that the need to put in a more hefty recursion check is entirely down to allowing outside-of-setprop/getprop access to the backing custom property store which has been conjectured to be used 'out in the wild'. Of course, we have no data as to whether this is the case or not, but I think we can all assume that is probably pretty rare. Thus it would be rather silly to do a lot of work in the engine to continue to support that use-case moving forward.

If we can make it so that existing scripts work the same as now - allowing new scripts to opt-in to the new behavior then no recursion check magic beyond what we have at the moment is required. Thus removing the only technical barrier I can see.

[peter-b]

I'd quite like Builder to have a more fine-grained signal/message system (maybe like GObject's) that lets specific signals/messages be blocked/unblocked. Then getprop/setprop could build on top of the primitives defined by the general mechanism rather than having to add special behaviour/rules. Just a thought to add to our "language & standard library development" list, @runrevmark.

[LCMark]

@FourthWorld: In actual fact even the 'special-case' recursion check (which is actually about checking for re-entrancy into the control whilst it's doing something) could be removed if we found a better way to express 'go to the backing array store of the custom prop directly'. As the engine doesn't have a direct syntax for doing this we have (instead) lock/unlock messages for outside the setProp/getProp handler and the internal re-entrancy check for within setProp/getProp.

I've been reasoning about re-entrancy a fair bit lately as it directly impacts widgets written in LCB and their interaction with script - thus far I think it comes down to a 'developer tax'. It is something you have to be aware of when writing your controls/widgets as the environment cannot really tell which is 'good' re-entrancy and which is 'bad'. For example, if you 'wait with messages' inside a mouseDown handler, you will likely get the corresponding 'mouseUp' message whilst 'inside' the mouseDown handler - is this good or bad? I suspect it depends entirely on what you are trying to do (and whether you knew of the possibility of that happening!). Hopefully as we get more explicit examples of what people are trying to do (particularly with widgets) then we can abstract out the patterns to simplify development.