Object-oriented programming AKA, OOP or OO refers to the subject-verb-object programming paradigm. A program is composed of abstract data types where the behaviour of each type is expressed as a set of routines (methods), and an object represents an instance of one of these types and contains the data that represent the state of the object. Alternatives to this include functional programming, although hybrid models also exist.
As of 8.6, TclOO is part of The Tcl Core distribution, and it is also available as an extension for 8.5.
Description
In object-oriented programming, programs are structured in terms of abstract data types. In class-based object systems, a blueprint for an object, called a class is created and then used to produce instances of that object. Other object systems do not provide the notion of a class, but instead provide mechanisms to copy existing objects, along with hooks that can be used to initialize the copy. The original object is called the prototype-based for the new object.
In class-based object systems, a class may inherit its attributes and methods from one or more other classes, forming a class hierarchy. Over time, it became clear that class hierarchies based on inheritance often constrain the program design in ways that are initially unforeseen. Composition, in which smaller, purpose-built objects are aggregated into a more object, is one strategy that can alleviate some of the problems of inheritance. Delegation is another strategy that can be employed to extend or wrap objects.
Instead of being data-centric, OOP becomes interaction-centric. In the pathological case, OOP makes each piece of data into a program object with its own behaviour, creating a combinatorial explosion of opportunities for a system to misbehave.
There are activities such as object oriented analysis (OOA) and object oriented design (OOD) that concern themselves with analyzing a system (or a solution to a problem) in terms of objects and their behaviors.
In Tcl, objects and classes are usually inplemented as commands, and the state of the object is stored in some namespace associated with the command. namespace ensemble is a building block for object systems. As of Tcl version 8.6TclOO is built-in. It also uses namespaces, but is an entirely separate mechanism from namespace ensemble.
Principles
An object should not change any shared state.
An object should be fully configured prior to first use.
An object should not be reconfigured after first use.
Quotes
The big idea is "messaging" ... If you focus on just messaging - and realize that a good metasystem can late bind the various 2nd level architectures used in objects - then much of the language-, UI-, and OS based discussions on this thread are really quite moot.
Object-oriented analysis and design's underlying concept is that one should model software systems as collections of cooperating objects, treating individual objects as instances of a class within a hierarchy of classes.
— Grady Booch
I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.
In other words, how you support good programming techniques and good design techniques matters more than labels and buzz words. The fundamental idea is simply to improve design and programming through abstraction. You want to hide details, you want to exploit any commonality in a system, and you want to make this affordable. I would like to encourage you not to make object-oriented a meaningless term. The notion of ‘‘object-oriented’’ is too frequently debased by equating it with good, by equating it with a single language, or by accepting everything as object-oriented. ...I have argued that there are – and must be – useful techniques beyond object-oriented programming and design. However, to avoid being totally misunderstood, I would like to emphasize that I wouldn’t attempt a serious project using a programming language that didn’t at least support the classical notion of object-oriented programming. In addition to facilities that support object-oriented programming, I want – and C++ provides – features that go beyond those in their support for direct expression of concepts and relationships.
I will, in fact, claim that the difference between a bad programmer and a good one is whether he considers his code or his data structures more important. Bad programmers worry about the code. Good programmers worry about data structures and their relationships.
PYK 2023 10 12: In other words, Object-oriented programming is bad programming.
Discussion
APN: For the benefit of newcomers to Tcl who might get confused by the large number of OO extension, the TclOO framework is part of the Tcl core language as of version 8.6. It is also available as an extension for 8.5. The list of extensions discussed in this page were created in earlier versions where Tcl lacked a built-in OO facility. The most notable of these, which still have relevance because of widespread use and features, are incr Tcl (now built on top of TclOO), Snit (because of its excellent support for Tk megawidgets) and XOTcl (which continues to add leading edge oo capabilities). The rest IMHO are useful only if you are stuck with older versions of Tcl and only of historical interest otherwise.
DKF: Fundamentally, OO in Tcl means that you've got an ensemble-like command (i.e. a command with subcommands) and some internal state model associated with that command (and manipulated by the subcommands) that goes away when the object is destroyed. That's all that's required. Everything else (including classes) is optional, if often useful to have. Note that according to this definition, Tk uses an object system for its widgets.
wdb: The benefit of object orientation is doubtlessly its information-saving and hiding capability. Possibly oo is mainstream nowadays. If a language is purely object-oriented such as Ruby, then it is ok. But oo is not the one true solution. If a language has a different paradigma such as Tcl and others, then it's nice to have the opportunity to use oo, but not to forget that there are other mechanisms of information hiding. I have used both, Itcl and Snit, and both do a good job in their way, but in some cases I prefer more language-generic mechanisms such as procedures originated in namespaces where they have private information as well. The true benefit of Tcl is imho the opportunity to use more than one oo extension in one application. This makes Tcl unique compared with the other scripting languages.
Tcl appears ambivalent, at best, about object orientation. Darren New has suggested that "the need for OO techniques is greatly reduced by a language with eval and info and dynamically-sized structures built in."
DKF finds subclassing for GUI configuration suboptimal.
RS: In a smokebreak, I whipped up this hierarchy of things, by weight:
1. process
2. thread
3. interp
4. namespace
5. commands, persistent vars
6. local vars
7. values (TclObjs) - strings, lists, dicts, ...
Every "heavier" thing can contain zero or more of "lighter" things. And on each level one can implement "objects". Most use 4., TOOT uses 7. procs with -static variables could allow (some) OO in 5. Databases are (fat) objects at level 1.
As RS aptly observes in "interp alias", object methods can be described as syntactic sugar for a certain form of dispatching.
RS 2005-03-27 interrupts: I'd even go further and say that quite a bunch of what is called OO can be done in pure Tcl without a "framework", only that the code might look clumsy and distracting. Just choose how to implement instance variables:
in global variables or namespaces or in closures, e.g. with Jim or
The task of frameworks, be they written in Tcl or C, is just to hide away gorey details of the implementation - in other words, sugar it :) As an example, here's a Stack class with push and pop methods:
namespace eval Stack {set n 0}
proc Stack::Stack {} { #-- construktor
variable n
set instance [namespace current]::[incr n]
namespace eval $instance {variable s {}}
# $object method arg.. sugar
interp alias {} $instance {} ::Stack::do $instance
}
proc Stack::do {self method args} { #-- Dispatcher with methods
upvar #0 ${self}::s s
switch -- $method {
push {lappend s {*}$args}
pop {
if {![llength $s]} {error {stack underflow}}
K [lindex $s end] [set s [lrange $s 0 end-1]]
}
default {error [list {unknown method} $method]}
}
}
proc K {a b} {set a}
Other examples for this framework-less "bare-bone OO" are at Skeleton OO, A little IO stack, Tiny OO with Jim, and Jim closures. A framework would just have to make sure that the above code is functionally equivalent to, e.g. (in a fantasy OO style):
class Stack {
variable s {}
method push args {lappend s {*}$args}
method pop {} {
if {![llength $s]} {error {stack underflow}}
K [lindex $s end] [set s [lrange $s 0 end-1]]
}
}
which, I admit, reads definitely better. But bare-bones has its advantages too: in order to see how a clockwork works, you'd better have all parts visible :)
History
In 1974, Liskov and Zilles used the term operation cluster to describe the implementation of an abstract data type, and the term functional abstraction denoted operations that weren't specific to the definition of some abstract data type.
Class-Based Vs Prototype-Based
Class-based systems are suitable for static languages where an object can not exist prior to runtime and therefore relationships between objects must be specified such that they can be processed by a compiler. In Dynamic languages where objects can be manipulated at runtime it is possible to use the more general and powerful prototype object systems. Class-based systems continue to be used in dynamic languages primarily due to inertia.
A stark example of how the OOP approach of packaging up both type (attributes) and class (behaviour) ends in subtle pathologies.
PYK 2016-01-26: In the natural world, type is a strictly abstract thing that arises from the study of kinds of things which actually exist in the physical world. In class-based object-oriented programming, this is inverted such that kind (instance) is always derived from type (class). This break with reality leads to many of the difficulties that arise in object-oriented programming, particulalry in regards on inheritance. The strict hierarchy of types is an unnatural constraint that often gets in the way of modelling systems as they are.
intended to be generic enough to use with various Tcl OO packages
Brief List of Popular OO Frameworks for Tcl
Since the comprehensive list (below) has grown very long, here is a short list (in no particular order) of some OO frameworks that are in very widespread use.
Distributed with Tcl 8.6 and higher, and also available for Tcl 8.5. Designed as a platform for building object systems, but all usable as an object system in its own right.
pure Tcl package, bundled with Tcllib, ActiveTcl. Close to C++ in design
Comprehensive List of OO Frameworks for Tcl
Some of these frameworks are intended for general-purpose deployment; others were developed to satisfy the requirements of a specific project. Some of these frameworks are no longer maintained.
Category Object Orientation lists several other projects that use a minimum of code to provide a subset of object-oriented facilities.
less than 100 lines, super-simple, aimed at people who want a small amount of object-oriented functionality (objects, member functions, memory cleanup, member vars) implemented in simple, comprehensible Tcl that won't gum up your environment, complexify your debugging or break debuggers.
dynamic Object-Oriented Programming extension for Tcl, featuring program styles, inheritance, meta objects, automatic method combinations, mixing of C and C++
NX is a highly flexible, Tcl-based, object-oriented scripting language. It is a descendant of XOTcl and was designed based on 10 years of experience with XOTcl in projects containing several hundred thousand lines of code. While XOTcl was the first language designed to provide language support for design patterns and to provide a highly dynamic programming environment, the Next Scripting Framework (NSF) and NX add to these features support for language-oriented programming.
Could be described as yet another object system for TCL, but in reality it is a methodology for open ended program design, and code re-use. Uses sqlite for metadata storage.
Tcl 8 based object oriented extension. Provides Java or C++ object syntax to Tcl. Adds items like multiple inheritance, data encapsulation, virtual functions and RTTI (Run Time Type Info)
A value-added replacement for the MITOTcl object system. Flexible, with mixins, filters, multiple-inheritance, and more. One of the more popular object systems for Tcl.
a minimal pure-Tcl OO system that allows (but not requires) to distinguish objects and classes. poor-man's objects, a variable-proc pair that is renamed away when the string dies