No registered users in community xowiki
in last 10 minutes
in last 10 minutes
[Xotcl] re: Method inheritance on class side
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Tue, 24 Apr 2001 15:16:20 +0200
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
Date: Tue, 24 Apr 2001 15:16:20 +0200
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