Re: [Xotcl] info method behaviour (interface proposal)

From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 14 Aug 2001 04:10:01 +0200

> 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.