Prev: BLT Tree Performance Question
Next: Problem with Expect/netcat/telnet
From: InetDavid on 5 May 2010 14:14
One thing I've really come to miss in TclOO from Ruby is the way that
you can inspect classes and objects. Tcl typically has used the word
introspection to mean 'command used to return information about some
aspect of the tcl interpreter's state'. (http://wiki.tcl.tk/9922) and
TclOO has extended the "info" command to inspect objects or classes.

In Ruby though, the objects themselves have methods to tell you about
their own behavior. For example, you can find out the class of an
object by using the "class" method on an object ( Object.class =>
Class).

While working with TclOO classes I've written the following methods to
display a (simplified) list of methods available to a particular
object. (I say "simplified" because I don't currently check for
methods in filters or mixins.) It walks up the tree of superclasses
and gets the methods from each superclass recursively:

oo::define oo::object method methods {} {
return [lsort [my Methods [list] [self]]]
}

oo::define oo::object method Methods {methods object} {
if { [info object isa class $object] } {
set methods [concat $methods [info class methods $object]]
set class $object
} else {
set methods [concat $methods [info object methods $object]]
set class [info object class $object]
set methods [concat $methods [info class methods $class]]
}
foreach superclass [info class superclasses $class] {
set methods [my Methods $methods $superclass]
}
return $methods
}

By adding these methods to the oo::object class I can then list all
methods for any instance:

% oo::class create a {
method aa {} { puts "aa" }
}
::a
% oo::class create b {
superclass a
method bb {} { puts "bb" }
}
::b
% b create my_object
::my_object
% my_object methods
aa bb destroy methods
% my_object bb
bb
%

What's the best way to add that to my oo::object class automatically?
Would this be better implemented in the oo::Helpers namespace (and if
so, how would this best be done)? Would this type of thing be useful
enough to integrate into the TclOO base?

There are many more methods for the Ruby Object class
(Object.methods.length => 182) which make it very easy to "play" with
Ruby objects and find out how they work, even without documentation.
You can see some samples at http://www.artima.com/forums/flat.jsp?forum=126&thread=171456.

David
From: Donal K. Fellows on 5 May 2010 17:32
On 5 May, 19:14, InetDavid <inetda...(a)gmail.com> wrote:
> While working with TclOO classes I've written the following methods to
> display a (simplified) list of methods available to a particular
> object.  (I say "simplified" because I don't currently check for
> methods in filters or mixins.)  It walks up the tree of superclasses
> and gets the methods from each superclass recursively:

It was a foundational principle of TclOO to keep such things *out* of
the base classes so that classes with very clean interfaces can be
generated. After all, as you've shown, they can be scripted in. I'd go
for making your own class hierarchy, with oo::object and oo::class
above (and almost entirely unused in a direct sense).

> What's the best way to add that to my oo::object class automatically?
> Would this be better implemented in the oo::Helpers namespace (and if
> so, how would this best be done)?  Would this type of thing be useful
> enough to integrate into the TclOO base?

oo::Helpers is a namespace of ordinary commands that are available in
every method body, but which don't make any sense elsewhere. Currently
only has [next] and [self] by default; [my] is actually private to
each object (which is very useful for callbacks).

> There are many more methods for the Ruby Object class
> (Object.methods.length => 182) which make it very easy to "play" with
> Ruby objects and find out how they work, even without documentation.

Sounds like a mess to me. :-) TclOO has three introspection systems,
[info object], [info class] and [self]. These are for inspecting
objects (including class objects, of course), classes, and the current
method call, respectively. I suspect that the capabilities of [self]
are not good enough, but the other two give you access to everything
the objects and classes know about themselves. The level of
introspection on individual methods is variable; "normal" procedure-
like methods will tell you a fair bit, forwarded methods have less to
say, and general C-implemented methods currently say nothing much at
all.

Donal.
 | 
Pages: 1
Prev: BLT Tree Performance Question
Next: Problem with Expect/netcat/telnet