[[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
[http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/Bundles/chapter_5_section_1.html]
and then
[http://developer.apple.com/documentation/MacOSX/Conceptual/SystemOverview/Frameworks/chapter_7_section_1.html] 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: [http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=bjpf3o%24ge9%241%248300dec7%40news.demon.co.uk&rnum=4&prev=/groups%3Fq%3DDIY%2Bmegawidgets%2Bgroup:comp.lang.tcl%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3Dbjpf3o%2524ge9%25241%25248300dec7%2540news.demon.co.uk%26rnum%3D4%26filter%3D0])  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:
[http://martinfowler.com/bliki/InversionOfControl.html]). 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.

----
[Category Glossary]