Purpose: to discuss the structure of the physical code in a Tcl module

----

[Peter Hiscocks] writes in news:comp.lang.tcl :

I hesitate to mention this idea, because it seems so obvious. However, I haven't read it in any of the excellent books on Tcl/Tk and have found it to be extremely useful.

I suggest that any Tcl/Tk program can be broken down into four major sections. As stated in the header from one of my programs:

 # Structure of this program:

 #       Part 1: Definition of all the procedures 
 #       These are used by other sections of the program.

 #       Part 2: Definition of constants

 #       Part 3: Creation of the widgets
 #               - menus
 #               - frames and controls

 #       Part 4: Initialization of system, launching event loop.
 #       This must be at the end of the code because it refers to
 #       procedures and widgets that must be defined previously.

These sections are not necessarily of similar size. Part 1 and 3 tend to be much larger, and Part 4 can be as short as a few lines of code.

This structure clarifies the event-loop based nature of a Tcl/Tk program. You set up the data structures and then start the event loop. What happens after that depends what events are triggered.

It also helps organize the program. For example, the procedures and
constants should be known when the widgets are created.

In the body of the code, I indicate the start of each section with something like this:

 #--------------------------------------------------------------
 # Part 4: Initialization
 #--------------------------------------------------------------

These 'section demarkations' can be very helpful in narrowing down the region of the program to search for some particular piece of code.

Comments?

Peter

----

[Donal Fellows] replied:

I consider section 3 to be better split between sections 1 and 4, and it
is often a good idea to split section 2 off into a separate file so your
system installation and configuration applet (:^) can manipulate that
more easily.

Much larger programs are better divided up into functional areas, so code manipulating Foobars goes in one file (or even directory if there is a lot of it) and code manipulating Spongs goes somewhere else.  This makes maintaining it much easier as you can identify what needs to be fixed with where to look for the code that needs fixing.

----

[Bryan Oakley] says:

I tend to not be so formal with naming sections. But what I do do (that always sounds so weird...) is put a main() at the top, and call it at the bottom. I like the main logic to appear first, with the details hidden below. Something like this:

    #!whatever
    
    <constants get defined here...>

    proc main {} {
        yada yada yada
        foo 420
    }

    proc yada {args} {
        ...
    }
    
    proc foo {} {
       ...
    }
    
    main