Custom Properties

Brian Yennie briany at qldlearning.com
Wed Apr 12 18:38:21 EDT 2006


For me, it's mostly just syntactic appeal. I like the "feel" of 
extending the language. For example, a while back I wrote an external 
to rotate Quicktime player objects. Images already had an "angle" 
propertly, so it felt natural to implement my own for players. I'm not 
ashamed to say it... it just seemed "cool" to be able to really extend 
the language instead of always introducing new handlers.

One thing I *do* like about using a custom property is that it's very 
clear what the target of your action is. With a handler, one may be 
more likely to obscure what object(s) are actually affected by the 
change. I also like that it gives you a natural way to actually store 
the persistent custom property with the object - not that you couldn't 
do that in a hander as well.

Perhaps a middle ground between the appeal of addressing properties 
which "feel" like properties and also making clear that it's calling 
custom code would be to adopt a naming scheme. Something like:

set the custom_angle of player 1 to 90
instead of
set the angle of player 1 to 90

Might make it clear that a setProp handler is involved rather than the 
Rev engine.

In the end though, I would say it's really more of a preference of 
style in the same way object-oriented versus functional or procedural 
programming can be debated. What makes it particularly interesting to 
think about in Rev is that Rev isn't inherently one style or another. 
Simply debating whether Rev is object-oriented or not has created some 
mammoth threads in the past =)!

> I have thought about doing this many times, but I usually revert back 
> to using a command or function handler instead, probably out of habit. 
> For example, the above could also be done by:
>
>   setEditMode true
>
> rather than using a property assignment like "set the editmode...". 
> For me, seeing a handler name informs me that there is a related 
> script somewhere. Setting a property doesn't give me the same, 
> immediate knowledge; later on when I've forgotten why I wrote a script 
> a certain way, seeing a statement that sets a property doesn't tell me 
> as clearly that a lot of other actions will be taking place at the 
> same time.
>
> Now I'm curious what's the advantage, if any, of using a setProp 
> handler over a standard command handler? This isn't just to you, 
> Devin, but to anyone who uses these regularly.




More information about the use-livecode mailing list