Why object orientation? Thoughts on OO, Natural language, human thinking. To put it simply, TCL is a simple language. For this language, simplicity should not increase application complexity. The more one interacts with TCL, the more "verbs" (commands) one needs to know. This causes cognitive load.In an analogy with natural language, more new products come in, but the 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. A 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 the 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 a 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. This should be "TCL way of object orientation", I feel.
Example usageHere 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 a 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 you 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.ImplementationTo implement generic commands that can map to specific commands based on object type or data type. We need to have types and the object should carry directly/indirectly the type information. C implements user-defined types by struct. The same way we can define it with arrays. What is more important is to 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 variables.In the above "a" object is an an array. It has a key "handler". In case of counter object, the handler value is "counter". In case of mylist object, the handler value is "mylist". Here typehandler, indirectly denotes the type. (Analogous to #! giving the handler for files in Unix )Here is the implementation of "proc >"
proc > { args } {
set obj [lindex $args 1 ] # get the object reference
upvar $obj myobj
set handler $myobj(handler) # get the handler for the object
eval "$handler [join $args]" # invoke the handler and pass the request
}The typehandler, type, class all refer to the same thing. It is a proc. It sees the command and dispatches to the relevent code-block implemented as switch. This implementation can be done any way desired. An example implementation of counter type.Here is the implementation of type 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
}
# method dispatching is done by switch.
switch $action \
create {
array set myref [list handler counter]
array set myref [list count 0 ]
}\
add {
# instance variables are nothing but array elements,
# here array key count holds an instance data.
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)
set new_val [ expr $pres_val - $decr ]
array set myref [list count $new_val ]
}\
get {
return $myref(count)
} \
reset {
array set myref [ list count 0 ]
}
}Implementing inheritance.By adding default clause to the switch and invoking a parent handler in the default clause, inheritance can be implemented.Implementing type handler in CIt is easy to implement the handler in "C" also. The "C" program needs to register only one procedure, i.e., the handler procedure. The object should be an array with key "handler", having the value as the name of the procedure. The method dispatching should be done by the "C" handler procedure.An example implementation of mylist package require Tclx
proc mylist { 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 { # instance variable is kept in the key "list"
array set myref [list handler mylist]
array set myref [list list {}]
}\
add {
set elem [lindex $args 2 ]
lappend myref(list) $elem
# array set myref [list list $new_list ]
}\
sub {
set index [lindex $args 2 ]
set index [lindex $args 2 ]
lvarpop myref(list) $index
# array set myref [list list $new_list ]
}\
get {
return $myref(list)
} \
reset {
array set myref [ list list {} ]
}
}The standardThis is more of a glueing standard and leaves room for different implementations. Since TCL is a glueing language. Implementation can be done in "C" or whatever. Here is a more precise definition of the standard.There are "generic commands" besides the normal commands of TCL. The generic commands are invoked with the following syntax. Note all generic commands invocation begin with ">"
> %command_name% %object_name% %other_args% ..The object is an array with minimum one key called "handler". Instance variables can be implemented as other array keys. The handler gives the type-handler to handle the command.Handlers can be implemented in many ways. It is typically a proc. As time goes, I will add more type implementations. I prefer to use the term "type" instead of "class".Some later thoughts ...It seems syntax need not be standardised but what must be standardised is Object Representation.See discussion below.Some Type Implementationsvkvalli
DiscussionsRS So, to summarize, you propose:
- one proc per class as constructor and method dispatcher
- one array per object, which identifies which class it belongs to
- a ">" command for all OO actions
interp alias {} $name {} > $nameBut it takes one extra array lookup to determine the class handler.vkvalli After some thought, this what I concluded.
- object-method invocation - format need not be standardised, that again can be changed to suit people's taste, whether ">" string or some other string. But I feel it is better to have "verb-object" style. For a more elaborate discussion on this, see Thoughts on OO, Natural language, human thinking.
- constructor, method dispatcher - can be same or different.
[RVM] At the end of both vkvalli's posts on the subject there appear some cliché opinions cutting short the thought.> While your proposal is an interesting new syntax for OO, I don't understand how it makes anything easier than it already is.That's not about the syntax, obviously. Citing vkvalli (above on the page): " ... the difference [is] 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 ... [and] ... for a more elaborate discussion on this, see Thoughts on OO, Natural language, human thinking".
