setProp/getProp and lock messages

[FourthWorld]

Answer is the #1 reason some form of escape is needed.

Yes... sorry I meant that ask and answer dialogs would just close but custom modals would toplevel.

Ah, right. Thanks for the clarification. Agreed.

It kills me when I make a mistake in a resizeStack handler in LC.

Indeed it's painful and causes data loss if you didn't save before you are forced to quit...

Aside from a significant difference in performance, the simpler error handling is the only thing I miss from MC these days.

Seven months in and LiveCode is only half open source.

To be fair open source projects aren't required to accept contributions.

Fair enough, though given that this is one of the few scripting tools that eats its own dogfood (made in its own language), the user base is in an unusually good position to help fix bugs and add optimizations.

I myself advised Ben not to bother until the real problem is resolved. It's just too much of a headache for them unless they can very easily see the changes being contributed. I'm not sure if the reality escapes RunRev that we could have a much better IDE with just one (probably part time) resource acting largely as an integration/project manager coupled with community contributions and the tweaks the rest of the RunRev team makes for bugfixes, engine and environment changes.

Hard to say. I agree that a community manager for the IDE could do a lot of good, but in the nearly complete absence of any communications about their IDE plans we have little guidance to imagine what those plans might be.

[LCMark]

Are you saying it's dirty and underhanded to ensure the recursion doesn't occur? I guess it might be possible for someone to rely on the recursion in some way...

It's the exception to the general rule that I find a little dirty and underhanded - whilst there are 'special-cases' to other engine messages (such as mouseWithin etc.) that is more to do with performance, i.e. not flooding scripts with a large number of unhandled messages and a more intelligent mechanism in the engine (at some point) would mean they could be eliminated. The setProp/getProp case exception (to do with recursion) is something that is needed to allow their functionality to work effectively which means they aren't quite the same as other messages - however, pragmatism must prevail in this particular instance

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.