Behaviors and the message path
ahsoftware at sonic.net
Fri Dec 9 04:31:54 CET 2016
On 12/08/2016 04:40 PM, Bleiler, Timothy wrote:
> Thanks Mark. I probably shouldn’t have used the word “problems” anywhere in my post. I agree, there are terrific benefits with the current implementation of the behavior feature. My main concern was insuring that what I observed was intended. If everything I described is by design, then the “inconsistencies” I noted are in my conceptual model of the language (extended object message path vs concatenation of scripts). Is there a better model that accounts for how the engine implements behaviors than an unpredictable combination of the two I’ve identified? An oversimplified understanding of how the engine processes scripts can get even experienced developers into trouble. The dictionary entry on "behavior" only hints at the full power of the feature and it might be difficult to expand it without invoking an accurate model of the engine’s rule set for behaviors.
I think the best explanation of the message path is still Richard
Gaskin's chart and web page. Although I have to give props to Dar Scott
for his message primer as well.
I tend to think of behavior scripts (and I know there are other
viewpoints on this, so ymmv) as private backscripts fitting into the
message path right behind the objects that use them. And in that sense
behavior scripts have the same functionality as other library scripts:
behavior handlers extend the functionality of an object or a group of
behaviors can be chained: for me this makes them more useful than
substacks, since you can't have substacks of substacks, but behaviors
allow me to have a library with compartmentalized functionality, i.e., a
math library with a special section for imaginary or complex numbers.
behavior handlers can be overridden: a handler in the library script is
in the message path unless a handler of the same name is earlier in the
ahsoftware at gmail.com
More information about the use-livecode