Wide open behaviors

[dunbarx]

Is it a big thing to think that behaviors might not be limited to buttons? Why not have any object, including stacks, be the repository of a behavior script?

Craig Newman

[FourthWorld]

I argued for that back when the implementation was still in early beta. As adamant as I was initially I've come to be okay with the implementation as it is, since it really doesn't matter what sort of object holds the script: none of its own properties come into play, since using "me" refers to the instance and not the behavior.

[Mark]

Hi,

I believe it would have been more elegant if RunRev had created a special, new object to store parent scripts in. They might have called it a class object, to lure OOP advocates.

Mark

[FourthWorld]

I believe it would have been more elegant if RunRev had created a special, new object to store parent scripts in. They might have called it a class object, to lure OOP advocates.

Agreed. Such things would also make great virtual objects we could use with behaviors to implement more OOP-like architectures.

Hopefully somewhere down the road....

[ooper]

I agree. I think that it would be a good thing to have a non-UI object hosting the behavior. Moreover, it would be useful if these could be created dynamically from a prototype --as it is now, but once created the new instance would hold its own runtime state that is privately, protected or globally accessible to the application (e.g., no path to a physical object on a stack). Ideally, these objects could contain behaviors from multiple prototypes. Finally, you could make these objects persistent --or contain hooks to become persistent.

This does not require changing the current Behavior. I still like the current approach, because a behavior is nicely encapsulated. Plus the fact that it lives in a button it can contain unit tests in its mouseUp event and can be copy-and-pasted anywhere!

/Carl

[WinstonJenks]

If any of you have seen the Toolbook product, this is what they call "shared scripts". And they are kept someplace in the stack not in a UI element. The really nice thing is there is a built-in user interface to select the shared script from the repository of shared scripts. No finding your button, and then typing in the name, misspelling it as you go... But keeping the script in a button is not too bad, but the language has commands to create and delete shared scripts as well. Actually, I think the Rev way is more flexible, but more work too because there is no behavior "picker".