The section, "How to write the main.tcl for a starkit" in "[Starkit - How To's]", presents
a coherent and correct model for organizing [starkit]-oriented [Tcl] coding.
Jean-Claude highlights there construction which allows the same source to be
run unwrapped, within a starkit, within a [starpack], and so on.  It's important to
understand the benefit of this.  While I don't have a satisfying way yet to express
it, the idea is something like this:  to make the best advantage of existing software and experience
in Tcl development, projects need to look "physically" as they always have:  a main.tcl
which [source]s other local Tcl scripts.  If the project can be maintained either as a
conventional [pure-Tcl] bundle, '''or''' a Starkit [VFS], then it'll enjoy the advantages
of both modes.

"How to write ..." aims at [package]-structured projects.  As desirable as "packagization"
is, this page presents an alternative, "package-less", outline for code maintenance that's
even more lightweight.  It also has the minor advantage that it doesn't expose the
"magic suffix" '''myapp.vfs''' in the code to be maintained.  Moreover, it is, I believe,
the most direct answer to the questions raised in one particular thread
[http://groups.google.com/groups?th=a296bd2cf22febd2]
in [the comp.lang.tcl newsgroup].

This is the construction:  . . .

[[Why is this here rather than within the Starkit Wiki
[http://www.equi4.com/starkit]?  The benefit is to subordinate Starkit details to a 
focus on Tcl coding
and the development process.]]

[[... much more to say ...]]

[[Comment clt thread [http://groups.google.com/groups?th=a296bd2cf22febd2].]]







[How to create my first Starpack]

Attractive diagrams make 
"Anatomy of a starkit" [http://www.equi4.com/starkit/191]
particularly edifying.