A framework is a system that other programs can plug into. The framework retains the central control, managing how the plugged-in programs are utilized within the scope of the framework, what other resources they may access, and how those resources are accessed. A framework differs from a simple code library in that it retains overall control.
A framework is generally thought of as an infrastructure layer that on top of which other programs can be built, easing the development of those programs. In this sense, an operating system is an example of a framework, maintaining control of resources outside of the control of the program, while providing an API for managed access to those resources.
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 [L1 ] and then [L2 ] 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 DIY megawidgets , comp.lang.tcl, 2003-09-11, in which, Jonathan Bromley narrates discovering the difficulty of writing 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 InversionOfControl , Martin Fowler, 2005-06-26, for a typically-long-winded explanation). 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.