propertyChanged message

[Richard Gaskin]

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, 
testing...

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 FourthWorld.com                http://www.FourthWorld.com