Object orientation

Difference between version 148 and 149 - Previous - Next
'''[https://en.wikipedia.org/wiki/Object-oriented_programming%|%Object-oriented
programming]''' AKA, '''OOP''' or '''OO''' refers to the
[https://en.wikipedia.org/wiki/Subject%E2%80%93verb%E2%80%93object%|%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
('''[method%|%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 [Changes in Tcl/Tk
8.6%|%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 '''[Programming with
Prototypes%|%prototype]-based''' for the new object. 

In
class-based object systems, a class may [inheritance%|%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.

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
[Changes in Tcl/Tk 8.6%|%version 8.6] [TclOO] is built-in.  It also uses
[namespace%|%namespaces], but is an entirely separate mechanism from
`[namespace ensemble]`.


** Principles **

   An object should not change any shared state.:   




** 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.''

       -- [http://wiki.c2.com/?AlanKayOnMessaging%|%Alan Kay], 1998

   ''I'm not against types, but I don't know of any type systems that aren't a complete pain, so I still like dynamic typing.'':   — [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en%|%Alan Kay], 2003

<<br>>

    ''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

<<br>>

    ''I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind.'':   — [http://en.wikiquote.org/wiki/Alan_Kay%|%Alan Kay]
        
<<br>>

    ''An object or two may sometimes be nice, just like a glass of beer. But one shouldn't start drinking at breakfast.'':   — [RS] (probably said it right here!)


<<br>>

   ''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.'':   — Bjarne Stroustrup, [http://www.stroustrup.com/oopsla.pdf%|%Why C++ is not just an Object-Oriented Programming Language]
 


** 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.  [proc]s 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
   * just as parts of a transparent value, with [TOOT]

''end RS''

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 types%|%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
language%|%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.

   [http://okmij.org/ftp/Computation/Subtyping/%|%Subtyping, Subclassing, and Trouble with OOP], {Oleg Kiselyov]:   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.



** [TIP]s **

   [http://tip.tcl.tk/6%|%6]:   rejected

   [http://tip.tcl.tk/50%|%50]:   implemented in 8.6, on top of [TclOO].  Historical: [Integrating Itcl into the Tcl core]

   [http://tip.tcl.tk/257%|%257]:   describes what later became known as [TclOO]

   [http://tip.tcl.tk/279%|%279]:   was not completed, whereas 257 was.



** Benchmarks **

   [Comparing Performance of Tcl OO extensions]:   

   [Object Instantiation Test]:   implementation of the object instantiation benchmark of [Tcl OO Bench] in some OO extensions of Tcl.

   [tcl oo bench]:   comparison of OO extensions of Tcl is based on OO benchmarks of Doug Bagley's [http://www.bagley.org/~doug/shootout/%|%OO shootout], which includes '''Object Instantiation''' and '''Method Calls'''.

   [oo method calls]:   implementation of the method invocation benchmark of [Tcl OO Bench] in various Tcl OO extensions



** Tools **

   [objectwalker]:   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.

   [TclOO]:   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.

   [Snit's not incr Tcl] (Snit):   relies on delegation rather than inheritance.  Pure Tcl package, bundled with [Tcllib], [ActiveTcl]

   [incr Tcl], or '''itcl''':   binary package, bundled with [ActiveTcl] and also built into [Tclkit].  [incr Tk] and [Iwidgets] use '''incr Tcl'''

   [XOTcl]:   binary package, bundled with [ActiveTcl]

   [ClassyTcl]:   binary package. [ClassyTk] uses '''ClassyTcl'''

   [stooop]:   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.



*** Class-Based ***

   [AXL]:   syntax quite similar to itcl

   [BOOP] (Basic OOP). by [JohnBuckman%|%John Buckman]:   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. 

   [CASTE]:   based on Common Lisp Object System (CLOS)

   [ClassyTcl]:   Tcl and C based versions available

   [dkfobj]:   a predecessor of [oo2]

   [Dyso object system]:   deprecated for [Odys object system]:   

   [EGR MAF]:   multimeda applications framework, includes C++ and Tcl bindings

   [ical oo]:   circa 1993

   [incr Tcl]:   one of the most popular object systems for Tcl

   [jTcl Java-like object interface to Tcl]:   

   [MeToo], or  '''M'''eToo '''e'''mulates '''T'''cl'''OO''', by [APN]:   a (small) subset of 8.6 core's TclOO in pure Tcl
   [mkextensions]:   includes '''mkClasses''', a Tcl object class and methods mechanism

   [MIT otcl]:   dynamic Object-Oriented Programming extension for Tcl, featuring program styles, inheritance, meta objects, automatic method combinations, mixing of C and C++

   [MIT otcl megawidget system]:   

   [http://pdt.github.io/nso%|%NSO], by [pdt]:   Simple object system with single inheritance, tagging, forwarding, getters/setters, support for class libraries.

   [Object Tcl]:   A Tcl extension that allows one to use object oriented programming concepts from within Tcl and provides a tight object-oriented coupling to C++.

   [Object Tcl by Nagao Shijo]:   

   [Oblets], by [Koen Van Damme]:   yet another very simple object system for Tcl

   [obstcl]:   Small Tcl object system package

   [obTcl]:   A Tcl 7.[[45]] object and megawidget extension, supporting multiple inheritance, three new storage classes, and fully transparent Tk megawidgets.

   [Odys object system]:   

   [OO by dejong]:   OO extension that works in Tcl 7, Tcl 8, and Jacl

   [Pool (Kupries)]:   yet another OO Tcl-based system

   [scwoop]:   Simple Composite Widget Object Oriented Pacakge

   [http://groups.google.com/d/msg/comp.lang.tcl/O3mLW4kSxOo/ejRnaKHZaagJ%|%Something cute and fuzzy], [Mike Rogers], 2001:   a [pure-Tcl] [extension] that endows [namespace]s with [inheritance].

   [Snit's Not Incr Tcl]:   a pure-Tcl object framework which relies on object composition and delegation rather than object inheritance

   [sntl]:   Sam's (Non-Standard) Tcl Library

   [STERNO]:   Simple Tcl Extra Really Nice Objects

   [stooop]:   part of [tcllib].  Provides commands to extend Tcl in an object oriented manner.  Meant to be as simple to use as possible.

   [TAO], or [TCL Architecture of Objects], by [Hypnotoad]:   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++], by [Matt Newman]:   A pure Tcl implementation of incr Tcl.  

   [Tcl_OO] by [Joe Mistachkin]:   

   [Tclpp]:   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)

   [Iliadtool2 Tea]:   Follows the Java model, trying to implement the look of Java from a class definition perspective, yet remain syntactically consistent with Tcl.

   [tiny oo with jim], by [RS]:   

   [TODL]:   An easy way to build Tcl objects (to be used as an educational aid rather than a development tool) 

   [Transparent OO for Tcl], or [TOOT], by [NEM]:   unifies Tcl's traditional first-class [transparent] values (like string, lists, and dicts), with the [handle]-based OO types.

   [TOS]:   

   [xoins]:   An [XoTcl] class that emulates [snit]

   [XOTcl]:   A value-added replacement for the [MIT] [OTcl] object system.  Flexible, with mixins, filters, multiple-inheritance, and more.  One of the more popular object systems for Tcl.
   


*** [Programming with Prototypes%|%Prototype-Based] ***

See [Programming with Prototypes]



*** Aspect-Oriented ***

   [tclaop]:   Aspect Oriented Programming extension (experimental).  Based on the good work of stefan Sinninge Tclpp (version 1.2, pure tcl script).



*** Minimal ***

The following systems are novel, and marked by the lack of a mechanism to
create objects that are based on other objects or classes.

   [Gadgets]:   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


   [LOST]:   OOP that can be easily distributed across a network using [jcw]'s [Tequila].  Inspired by [Gadgets].

   [MOST]:   Like [LOST], but keeps data in arrays

   [sproc], by [AMG]:   instantiate [proc]s

   [Thingy: a one-liner OO system]:   although there is a procedure on the page for copying thingies.



*** Transparent ***

Object systems where the objects are plain strings, not commands or namespaces.


   [Yet another object system], by [jcw]:   [EIAS%|%Everything is a String]! 

   [Transparent OO for Tcl]:   See in ''Class-Based'' above.



** Half-Bakery **

Ideas that did not come to fruition

   [UPL: Command-Oriented & Object-Oriented Tcl/2]:   



** Reference **

   [http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay_oop_en%|%Dr. Alan Kay  on the Meaning of “Object-Oriented Programming”], an correspondance with Stefan Ram 2003:   

   [http://www.objs.com/x3h7/fmindex.htm%|%Technical Committe H7 Object Model Features Matrix], Doc No. X3H7-93-007v12b, 1997-05-25:   a comparison of object models


   [http://www.gener8.be/site/articles/tcl_objects/tcl_objects.html%|%Objects in Tcl], [Koen Van Damme]:   a guided tour of creating pure-Tcl objects without inheritance.

   [http://web.archive.org/web/20071017181547/http://www.unixreview.com/documents/s=9233/ur0407k/ur0407k.html%|%Object-Oriented Tcl], [Cameron Laird] and Kathryn Soraiz, 2004-07:   [APN] This article is hopelessly out of date.



** See Also **

   [Category Object Orientation]:   

   [The Anatomy of an Object System]:   A walk through the design of a minimal object system.

   [Closures]:   they aren't quite compatible with Tcl in its current form

   [oo]:   a page that should probably be folded into this one

   [ootcl]:   a page that should probably be folded into this one

   [Object vs. Megawidget]:   

   [advantages and disadvantages of oop]:   

   [a case for oo in the core]:   

   [Extending Tcl]:   

   [A simple comparison of Tcl object extensions]:   

   [On things]:   a thought experiment

   [Doing things]:   

   [Toasters and things]:   

   [Chaining Things], [MS]:   inspired by [RS]' "Things" writings 

   [Doing things in namespaces]:   based on [Doing Things]

   [playing OO], by [RS]:   
   
   [playing oo design], by [RS]:   

   [Meta-object protocol]:   

   [oo killed my brother]:   a facetious commentary

   [oo libraries]:   a mostly-historical, somewhat philosophical discussion

   [oo2] and [http://people.manchester.ac.uk/~zzcgudf/tcl/oo3.tcl%|%oo3], by [DKF]:   precursors to [TclOO]

   [Simple Closures and Objects]:   

   [thoughts on implementing oo in tcl], by [MS]:   

   [thoughts on namespaces and oo]:   

   [thoughts on oo, natural language, human thinking]:   

   [Playing with Circuits], by [RS]:   how OO can be a ''stylistic'' matter, with'''out''' syntactic scaffolding.

   [skeleton oo] by [RS]:   a template to roll your own object system

   [oo system for tcl9]:   circa 1991

   [http://phaseit.net/claird/comp.lang.tcl/ootcl.html%|%Cameron Laird's personal notes on object-oriented Tcl]:   historical

   [traits]:   another technique for organising object-oriented code

<<categories>> Concept | Object Orientation | Arts and crafts of Tcl-Tk programming