There is lot of discussion on whether to add OO in TCL base or not.

The best way to resolve is start developing libraries like "collector classes" , eg, a generic for-each command for lists,arrays etc
and let people start using them. More the libraries and more people using them, then things will find its place naturally.
 
The OO should not be inconsistent with TCL semantics. The first word is a "command" . Most OO implementations , make the first word "the object".

It should have TCL spirit. The base should have minimal stuff.
Impatient people skip the philosophy section to go to the concrete stuff

All it requires is to have a procedure with name ">" . The definition of "proc >" is given below.This procedure is some 4 lines.

'''OO philosophy'''
---- 
Why object orientation -? [Thoughts on OO, Natural language, human thinking ]. To put it simple, TCL is simple language. This language simplicity should not make application complexity. More one interacts with TCL more the "verbs" (commands) one needs to know. This causes cognitive load. 

Analogy with natural language, more new products come in, but number of "verbs" does not explode in the language. When you say "open the door" , "open the letter" , "open the computer". "open" is the verb. verb represents an action. More precisely, this action can be thought of as a sequence of actions. More precisely, if sequence of actions are mapped to verbs, then we will have "open_door" , "open_letter", "open_computer" verbs. This is because sequence of actions are different for "open_door", "open_letter".But we don't use it that way. Therefore the "open" verb  is a kind of generic "verb" that maps to specific verb "open_door" or "open_letter" based on the the type of object. This mapping happens implicitly in our mind.
Natural language evolution was based on the cognitive limits of human mind.

The same way TCL has commands. They are more like "verbs" but "specific verbs". They map to a unique sequence of actions defined in proc. We need TCL to support "generic commands" something like "generic verbs" , we use commonly in natural language. 


----
'''Example usage'''

This is "TCL way of object orientation", I feel.Here is an example.
Presently TCL supports data encapsulation this way say I have an implementation of counter, I use it 
this way

 counter_create a 
 counter_add a 1 # a will have 1
 counter_add a 3 # a will have 4
 counter_sub a 1 # a will have 3

 # For lists
 set a [ list {} ]
 lappend a ram # a will be { ram }
 lappend a somu # a will be { ram somu }
 lvarpop a 0 # a will be { somu }

Now there are different commands for different type of data/object . In the new model, here is how
the interaction will be. All "generic commands" will be prefixed by ">" . Note: ">" is not prompt.

 counter create  a 
 > add a 1 # a will have 1
 > add a 3 # a will have 4
 > sub a 1 # a will have 3

 # For lists
 mylist create a 
 > add a ram # a will be { ram }
 > add a somu # a will be { ram somu }
 > sub a 0 # a will be { somu }

Now see the difference. If u are teaching TCL to a school kid , they will surely see the difference in cognitive comfort in two modes. More than cognitive comfort, there are other productivity benefits too.
Say I can create another generic command "sum" that can receive a list of objects which can act on "add" command. Rest is OO benefits .. I need not dwell on that.

'''Implementation'''
----
To  implement generic commands that can map to specific commands based on object type or data type. We need to have a way types and the object should carry directly/indirectly the type information.
C implements user-defined types by struct. The same way we define it with arrays. What is more important is get the type information from the array. All objects are of type array with a minimum of one element having the key "handler". Rest of the array elements are instance variable.

Here  is the implementation of "proc >"
 proc > { args } {
  set obj [lindex $args 1 ]
  upvar $obj myobj
  set handler $myobj(handler)
  eval "$handler [join $args]"
 }

Here is the implementation of class counter:
  proc counter { args } {
    set ref [lindex $args 1 ]
    set action [lindex $args 0] 
    if [ string equal $action create ] { 
     upvar 1 $ref myref
     } else  { 
      upvar 2 $ref myref
     }

      switch $action \
           create { 
            array set myref [list handler counter]
            array set myref [list count 0 ]
           }\
           add  {
            set incr [lindex $args 2 ]
            set pres_val $myref(count)
            set new_val [ expr $pres_val + $incr ]
            array set myref [list count $new_val ]
               }\
           sub {
             set decr [lindex $args 2 ]
             set pres_val $myref(count)