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