Virtual Custom Property Sample - Recursion Limit Problem

David Bovill david at openpartnership.net
Sun Jan 14 08:49:18 EST 2007


On 12/01/07, Jim Ault <JimAultWins at yahoo.com> wrote:

> Lock messages=true  will mean the unwanted message will not be introduced
> into the hierarchy.  Actually, I find little or no value to the
> getProp/setProp behavior and simply program a normal handler to do the
> task.
> Every time I think that getProp will be an advantage, it turns out not to
> be
> and no pesky recursion to thwart.


I would strongly disagree with that. In nearly half of my handlers are now
getprop and setprop handlers. They have a number of strengths and a few
weaknesses. Recursion is not really one of the weaknesses as a call to a
getprop or setprop handler is in effect equivalent to "sending" a handler to
an object - you get recursion in exactly the same way in both cases.

On 12/01/07, Richard Gaskin <ambassador at fourthworld.com> wrote:

And FWIW, using getProp/setProp benchmarks a tad slower than calling a
> handler, so it really depends on what you want to accomplish.
>
> One thing getProp/setProp do well is maintain a reference to a specific
> object, the target.  So if all you need is something procedural a
> handler will do, but if you need something to act on a specific object
> which may not be the target of a user interaction then getProp/setProp
> can be helpful.


I agree here - the syntax only really works if you are effectively thinking
of a specific Rev control ("object"). In addition you should be liited to
one or two parameters. I find both the thinking and the limitation very
useful. It helps you think less in terms of "libraries" and more in terms of
"objects" with properties, and it forces you to define interfaces which are
simpler and involve less parameter passing.

There are some other features which can be useful - for instance if you want
to not have error called when the handler is not present. You can then
either use "try" which slows things down - or use a getprop or setprop
handler - if they are not there then the call just returns empty.

There are a couple of problems / things I wish would be improved:

  1) getprop handlers can return arrays but you cannot pass an array as a
parameter to a setprop handler. Therefore "put the table_Array of fld 1 into
someArray" works fine, but set the table_Array of fld 1 to someArray" will
get you nowhere as the array is not passed.

  2) lock messages locks stops messages being sent and therefore any
recursion, but is badly designed in that it also blocks the initial call to
the getprop or setprop handler. This prevents a couple of very useful things
you could do when you start to try to design reuseable components.



More information about the use-livecode mailing list