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}
this is more or less what we have currently scheduled for 0.86 used as result for [self next] and [.. procsearch ....]. actually, having another order, such it has the same order as in the definition.
{b foo3 proc} {B instproc foo1} {A instproc foo2}
however, it would be still nicer to have methods as objects.
{m1 m2 m3}
[m1 class] -> Proc [m2 class] -> Instproc [m3 name] -> foo2
this would allow more methods on procs/instprocs and this is extensible with more metadata (e.g. pre/post conditions, c-code vs. tcl-code -> getting rid of the distinction of instcommand vs. instprocs ....).
Another interesting idea is to use aggregations for methods.
Class C C proc f {} {...} C instproc m {} {...}
would lead to C::f C::m where C::f amd C::m being of class Proc or Instproc
one could even use
Class C Proc C::f {} {...} Instproc C::m {} {....}
In the most straightforward case, this would exclude having instproc and procs of the same name, which is not great (OTH, other OO languages do not allow these either)... the cool part is that it is very easy to find out, where the command is defined, and moving, renaming etc. could work with the standard move/rename etc. methods, and "info procs" is not much more than a specialized "info children"....the long list of things in "info info" can be reduce....
but there are as well many arguments against it. one thing is memory consumption. to even think about it, we should find a way of defining lightweight objects....
-gustaf
PS: no, i am not thinking about implementing it, i am just thinking loudly.