ambassador at fourthworld.com
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
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
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?"
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
Ambassador at FourthWorld.com http://www.FourthWorld.com
More information about the use-livecode