propertyChanged message

Richard Gaskin ambassador at
Thu Sep 1 16:42:04 EDT 2022

Bob Sneidar wrote:

 > I would like to see a propertyChanged message implemented that gets
 > sent to any object when any of it's properties change. There could
 > even be two messages, one for built-in properies and another for
 > custom properties.

I like the idea (I'd love messages for all sorts of things), but 
conversations with Dr Raney remind me of the impact messages have on 
overall performance.

There are probably super-smart ways to implement things that don't have 
the drag on performance that mouseStillDown once imposed, or the 
limitations eventually placed on it to keep it from being a persistent 
source of performance loss.

But cleverness comes at a cost of its own, in design, implementation, 

This is worth considering, but perhaps we can start with the use case - 
thank you for providing this one:

 > Imagine being able to change the font or size of a particular object,
 > and then having all the other objects that "subscribed" to that
 > object's font or size property ALSO have their fonts change. It would
 > then be possible to build a kind of Object Oriented environment.

OOP systems are largely defined by their object model.

In LC's stack/card/control model, visual properties are inherited, so 
changing once at the stack level allows everything downstream to reflect 
the change, no code needed at all.

I can see cases where it would be nice to have CSS-like classes, where 
we could define style properties in one place and have everything 
assigned to use that set of properties automatically reflect changes.

I believe that level of style-sheet-like flexibility is something Mark 
Waddingham may have mentioned before. Bonus if it could use actual CSS 
syntax as an *option*, so newcomers can jump in quickly and old-timers 
can choose whether to enjoy the compactness of CSS or the completeness 
of LC Script, "set the x of y to x".

There are of course ways to do things like this using custom props, and 
I'll go out on a limb to try to channel Dr Raney on this, based on 
conversation I'd had with him about messages:

"Show me a use case where it's not possible to get what you need from a 
custom message, and I'll consider a way to override built-in messages."

His concern with messages was two-fold:

- Performance: the open-ended mechanism needed to allow overriding
   adds overhead to setting up the calling change each time the
   context changes, and sometimes during execution.

- Consistency: it creates a world of unpredictability, where simply
   using someone's library can alter messages you've been relying on
   for years.

I believe both of those can be seen as relevant to property changes.

And with that view, one attempt to satisfy this is provided with virtual 
properties: getProp and setProp.

Using custom prop names for custom behavior ensures that the built-in 
names will always reliably do what you expect, while still leaving open 
a boundless universe of options for custom behavior, simply by calling 
it via a custom name.

Within a getProp or setProp handler, one can get and set any number of 
built-in properties, and also custom properties, and call commands and 
functions, and set properties of other objects, and do just about 
anything LC Script allows.  Very powerful.

I know you're already very familiar with getProp and setProp, as are 
most of the readers here. So I'm not re-introducing them to be pedantic, 
or to gatekeep your request. I'm merely trying to understand your 
request in terms of real-world development needs.

So to help my understanding, I'll pose to you a variation of what Raney 
posed to me:

"What are you working on that can't be done by having custom property 
handling accomplished via custom property names?"

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list