Above all else before I begin, I really want to make sure it is understood that I am not recommending this in all instances, instead I am talking about relatively simple things, being relatively simple myself I tend to be drawn in that direction most
While I've seen scripts that are "long and snarly" as you put it, I think one of two things when I come across them most times -
- it required more complexity than I am suggesting using this method for, and using behaviors would be more appropriate probably in that circumstance, or
- the person writing it got tunnel vision of sorts and didn't take the time to break it down to more relevant handlers and functions.
In your example, suppose you don't want every button to change color, only some of them. So now you have two conditions to check for -- that the target is a button, and that the target fits a set of criteria, perhaps by comparing the name of the target to a constant holding a list. So now you have to look at the target, keep a list, get the name, compare it to the list, and remember to update the list if you add or delete buttons later.
When I started using Lc I was doing something like that. No lists, mind you, but using repeat to loop through controls and filter what I wanted or didn't based on name values.
Having come a tiny
bit further, I now put the empty handler in the button (card, stack, field, etc) to avoid the event in the mainstack, or alternately, call or send or dispatch the handler or function I wanted for that special snowflake button from which ever stack I decided it was optimal to put the handlers/functions in.
If you have a multi-stack program, certainly using a library would likely be the place to put those handlers or functions I think, if for no other reason than to keep them centralized to one location for editing later that isn't going to have any other kind of code in it.
... In fact, I am so enamored of libraries I pretty much can say I use those a LOT
, if for nothing else than keeping generic code around and easily accessible.
Using call, send, dispatch, etc has eliminated (so far) the need to copy/ paste scripts across stacks/cards/etc. for the stuff I do or have done, but again all my projects so far are very simple things.
I have no problem with using behaviors, although I'm sure it sounds like I do, reading my answers. If I had something that required some kind of complicated inheritance, or as you put it earlier, the equivalent of a class object, I'd certainly start digging right in.
I guess deciding when it is the most appropriate tool is going to be the challenge for me, certainly if any handlers I write for some object start to hit that 'long and snarly' mark, I'd be looking at it as it would have passed the 'relatively simple' mark.
Thank you again for all the insights though, I really appreciate the explanations and amount of thought put into them, you always give me lots to think about