AW: where to put handlers?

Devin Asay devin_asay at
Wed Feb 6 13:12:32 EST 2008

On Feb 6, 2008, at 10:24 AM, Richard Gaskin wrote:

> Devin Asay wrote:
>> I have two objections to placing all handlers high in the message   
>> hierarchy.
>> 1. It destroys the modularity/object-oriented-ish-ness of  
>> Revolution  stacks. If I create a particularly brilliant object  
>> (or at least a  complicated object that is "good enough") I often  
>> want to re-use it  in other projects. If I've separated the  
>> scripting from the objects  it becomes much more difficult.
> But sometimes that modest effort can pay big dividends down the road.
> For example, I have a table object that I use throughout many of  
> the apps I write.  It has a lot of code, and parts are rather  
> tricky, so if I replicated it I'd have a lot of replicated code and  
> if I need to change it I'd have a lot of work applying those  
> changes to each instance.
> So instead I have as little code as possible in the group itself,  
> and put most of the code in a library.  There's only one copy of  
> the code, and maintaining and enhancing it is a breeze.

Well said and well-argued, as usual, Richard. But I don't think we're  
saying two widely different things. When you put code that is  
specific to certain objects or groups into a library, you have still  
made it modular and easily portable. This is lots different than  
hunting down a handler or handlers in a huge stack or card script and  
hoping you have copied and pasted everything you need into the other  
>> 2. As a project grows in complexity, a stack script that  
>> contained  all handlers in the stack could easily swell to several  
>> thousand  lines. In this case it actually becomes *harder* to  
>> maintain, as you  must scroll or search through a huge script to  
>> find the handler  you're looking for.
> True, so I break my code up into separate libraries, each dealing  
> with a particular area of functionality (menu commands, file  
> management, etc.).
> In fact, menu commands are a good example of the benefit of  
> centralizing code, since having them all in one shared library  
> makes it easy to add contextual menus at any time.  If the code for  
> menu handling were in the menu bar I'd either have to replicate it  
> in the context menu, or use a lot of send commands.
> Finding handlers is a job best left for the computer.  My script  
> editor has had handler definition lookup for years, and Jerry's  
> does too.  I'm sure Rev will catch up sooner or later as well.
> So I agree with just about everything you wrote, but I'm not sure  
> there's a One Size Fits All answer to this question.
> Jerry's axiom is helpful, but the definition of "necessary" will  
> change from context to context. ;)

Absolutely. One of the strengths of Rev, and what makes it such an  
adaptable tool for developers' differing approaches, is the ability  
it gives you to structure a project any way that makes sense to you.  
Of course, that doesn't mean it will make sense to the next guy that  
looks at it. ;-)

Still, the idea of completely self-contained "objects" is very  
appealing to me--think Shao's or Sarah's calendar objects/stacks, for  
example. Many of these modular "objects" are so specialized that  
generalizing the code into libraries might not make sense. I think  
there's an important difference between reusable, modular, "objects"  
and libraries of common handlers and functions.



Devin Asay
Humanities Technology and Research Support Center
Brigham Young University

More information about the Use-livecode mailing list