Updated 2012-01-18 11:20:16 by dkf

[describe what the word framework means]

To some, framework is another term for library, or class, or set of functional code designed for one to build upon.

In general, the term 'framework' is generally thought of as an infrastructure layer. Using it makes doing some specific type of development easier.

In tcl, an extension designed to streamline the building of a megawidget might be called a framework.

[ DKF: I note here that "Framework" means something specific in relation to MacOS X, but don't understand exactly what it is. Can someone expand on this? ]

LV: Well, read [1] and then [2] is a part of the Mac OS X documentation and perhaps that will help a bit.

RS finds that Tcl/Tk themselves make a great framework. Earlier, I crafted my own convenience routines in Tcl, leading to package dependencies and less readable code... So I changed to using pure-Tcl as far as possible (and that's very far!) - see for example e.g.

If one has no need to repeat the identical functions, then writing everything from scratch is the result one will find.

Frameworks are based on the assumption that a) one does not wish to spend years writing the same code that someone else has already written, b) that the functionality one wants is either complex enough, or repetitive enough, that doing it once - right - and debugging it once, results in benefits to other.

See for instance the comp.lang.tcl thread titled "DIY megawidgets" (See: [3]) in it, [Jonathan Bromley] talks about his initial discovery of how hard it is to write a robust megawidget from scratch, and Bryan Oakley concurs... Having a debugged set of procs which handle these issues allows one to spend their time writing widgets rather than recreating the infrastructure.

NEM In Java-land, framework usually refers to a library built around the Hollywood pattern: "don't call us, we'll call you!" (AKA "inversion of control"). The idea is that the framework is in control and calls back to your code as needed. Tcl's event loop would be one example, where you register interest in events and the notifier calls you when those events are detected. Lots of Java libraries are built this way, e.g. J2EE. (See typically long-winded explanation: [4]). Another example would be the use of internal instead of external iterators. An external iterator (as found in Java's standard collection classes) is like a cursor into the collection. Your code calling the iterator is responsible for advancing the loop:
 while (iterator.hasNext()) {
     Object next = iterator.next();
     ...
 }

An internal iterator, however, does this inversion of control that is typical of frameworks (e.g., Smalltalk or Ruby collection classes). Here, you pass in the code you want executed for each item in the collection, and the collection controls the loop (Ruby here):
 collection.each { item | do something with item }

See my proposal for a generic collection traversal interface for more on why this is preferable.