Hi Mark,
On Jun 21, 2007, at 8:20 AM, Mark Wieder wrote:
Devin-
Wednesday, June 20, 2007, 5:04:05 PM, you wrote:
I tend to agree on this one. My rule-of-thumb is "2-3"; in other
words, if I need to execute the same code 2 or more times and that
code is more than about 3 lines, I'll break the code out into another
handler.
...that's pretty much my rule-of-thumb as well, but that's a separate
topic (albeit a good one for discussion).
My point was more about decoupling the bulk of the actual code from
the on-screen object event handlers: mouseUp, returnInField, etc. I
don't always do this, but if the handler grows to more than a couple
of lines I'll usually break it out.
I think I understand where you were coming from--it may be best to
leave the standard event handlers looking clean and easy to follow by
breaking out logically discrete blocks of code into handlers with
functionally descriptive names. I think I have a learned resistance
to this technique from my HyperCard days. Back then we were always
looking for speed tweaks, and somebody once ran some benchmarks that
determined that you took an ever-so-slight speed hit when calling
another handler as opposed to keeping all statements inline in the
existing handler. Add to that the absence of script-local variables
in HC--thus, the need to pass all data to the other handler as params
or declare bunches of global vars--and you have a behavioral aversion
to the technique. Which is not to say it's not a good practice. In
fact, I've used this approach when teaching students about custom
handlers.
Of course now, as of Rev 2.8.x, I can teach them that 'on <event>'
and 'command' handlers are two different things: use 'on' to trap
standard event messages and 'command' to write your own handlers. I'm
still pondering whether this distinction would gain me anything when
I'm teaching new Rev programmers. Do I gain anything by emphasizing
the somewhat artificial distinction between messages and commands?
Regards,
Devin
Devin Asay
Humanities Technology and Research Support Center
Brigham Young University
_______________________________________________
use-revolution mailing list
[email protected]
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution
