sure. the point is, that we need both: an explicit interface for getting the details right and for distinguising as far as neccessary, and a high level interface, that hides part of this details for a user who does not care about these. for the latter case, an "info procs" or "info instprocs" is not the right way, since the names are not necessarily disjunct. a new thing called "info methods" that returns a list of method-objects (see last mail) could help here returning all the callable methods (which are procs, instprocs, mixins, filters).
what is it, that would fit your needs best? what are you doing exactly?
Yes. I thing such new interface is needed
$object info methods
Is one to get all methods that object can understand.
Another one is to get additional meta information I use this method to get all instprocs and the place, where they are defined for my purposes.
Class instproc getAllFullInstMethods {} { set fmethods {} foreach m [[self] info instprocs] { lappend fmethods [list $m [self]] set marr($m) 1 } foreach class [[self] info heritage] { foreach m [$class info instprocs] { if {![::info exist marr($m)]} { lappend fmethods [list $m $class] set marr($m) 1 } } } return $fmethods }
Such think sould be implemented internally (and not so unclean) and can be used also for procs and mixins (instance or class).
$object info fullMethods myMethod sould return list {methodName methodType definitionPlace}
for example
Class A A instproc foo1 A instproc foo2 Class B B instproc foo1
B b b proc foo3
b info fullMethods
{foo3 proc b} {foo1 instproc B} {foo2 instproc A}
b info methods
{foo1 foo2 foo3}
I think the method type can be rather not needed if man use [Object isclass A]
Very similar interface is known by Smalltalk Object>>responseTo: method (return true or false if object understand message)
Behavior>>allSelectors (get all methods)
Behavior>>findSelector: method (get the definition class of method)
Artur Trzewik