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
____________________________________________________________________
[email protected] http://www.FourthWorld.com
_______________________________________________
use-livecode mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
