[Xotcl] re: Method inheritance on class side

[Gustaf Neumann]

On Sunday 22 April 2001 14:02, Artur Trzewik wrote:
> Hallo
>
> By building some Xotcl Class System I have following problem.
> Consider the example
>
>
> % Class A
> A
> % A proc test {}  { puts "method test" }
> % Class B -superclass A
> B
> % B test
> test
> %
>
> I would expect by calling B test to invoke A proc test and not to create
> new instance of B.
> I know this bahavior from Smalltalk. It is very usefull for building
> special creating method on class side or some method that not need a
> instance

 we discussed internally this topic about forteen day ago internally.
 the point is that 
   - "proc" is by its idea an object specific method 
   - the way to provide methods for other objects (in the general sense)
     in xotcl is primarily the instproc mechanism;
   - the preferred way to  provide methods for classes
     are meta classes

 one can use meta-classes, or even if you want to stick with
 "Class" class creation, you can combine metaclasses with instmixins 
 to achieve a similar behavior:
==========================================================
Class M
M instproc mt {} {puts "method meta test" }
Class instmixin M

Class A
Class B -superclass A
B mt
==========================================================

 in other cases, it is appropriate to search for some base-class
 an to call its proc via delegation. The per-object-philosopy
 (for the "eyes" of one object only) is something which can be
 desireable in some situations.

 a possible solution is to distinguish between 
    - proc
    - instproc
    - classproc
 where the last one is like a proc, which is intherited to subclasses.
 The danger i see there is the XOTcl becomes a kind of new version 
 of CLOS, which allows a very elementary configuration of all
 aspects of the language with tons of "modifiable language elements"

 aside the basic question of conceptual cleanness of what procs are
 supposed to be is the question of negative effects and compatibility. 
 Currently, calling a proc is very fast, the necessity to search for 
 another proc will cause some speed penalty. for other effects, 
 check the following incomplete list of further aspects:

   - method chaining between procs (of classes),
   - [self] of a proc is not alway the object, on which it is called,
   - inheritable procs in per-object or per-class mixins

 My feeling is that the number of occurances, where this inheritable
 procs are needed, is rather small (maybe it is my programming style).
 The issues involved are quite complex. in most (all) there is a 
 not-so-conveniant, but quite-clean solution for the problem. But
 my opinion is quite undecided.

 What is the opinion of the community? Do you need/want such 
 an extended "inheritable proc" or a new language-consttruct?
 Did you face this problem already, and if yes, was it hard/inelegant
 to solve?

 best regards
 -gustaf