Prev: Is it possible to specify in TclOO classes a kinds of operators? (e.g. == or "eq")
Next: Making a Scrollable Widget
From: George Petasis on 16 Feb 2010 05:39
στις 16/2/2010 11:53, O/H Donal K. Fellows έγραψε:
> Principally, because I suspect that those cases where people demand it
> are actually cases where inheritance is being misused. Inheritance is
> not for modeling rôles (that's what mixins are for) so where you've
> got multiple inheritance you really need to be thinking in terms of a
> class that is naturally a specialization of both its superclasses.
> I've yet to see a satisfying example of this, and I (probably) won't
> do anything about this until someone demonstrates a proper motivating
> example.
>
> So far, the only concrete example that anyone's tried involved widget
> classes, and that turned out to be an abuse because the child class
> was really not very much like one of the parent classes in that a
> dialog widget isn't subject to normal geometry management rules, etc.
>

If dialogs are a problem, you can transfer the same problem into
building an explorer like interface. Class A is a tree widget, class B
is an icon view widget. You want to create a class C that is an explorer
widget. C inheriting from A & B is the easiest solution, all methods
from A & B are there. Creating a new class C that delegates A & B means
new methods for C, forwarding them to A or B.
(I cannot comment on "mixin", as I haven't yet understood what it does :-) )

How is the suggested way to implement such a widget?

George
From: GN on 4 Mar 2010 07:55
This is a place where tcloo semantics differ from xotcl.
Here is your example in xotcl:

Class create foo; foo method init {} {next; puts foo}
Class create bar; bar method init {} {next; puts bar}
Class create foobar -superclass {foo bar}; foobar method init {}
{next; puts foobar}
Class create geek; geek method init {} {next; puts geek}
Class create mongrel -superclass {foobar geek}; mongrel method init {}
{next; puts mongrel}

The constructor "init" is in xotcl a plain method, which can be
overloaded eg. with mixins, etc. When an object of class "mongrel" is
created, the output is - more or less, what you expected.

geek
bar
foo
foobar
mongrel

If one is interesting to pass different arguments to init (in c++
style) one can do this by specifying the arguments along with next. In
general, xotcl's parametrization of objects provides a more
declarative way to initialize objects via non-positional arguments
(e.g. providing defaults, value checkers, etc.).

Concerning the transparency of the "call chain". xotcl provides "info
precedence" which prints the precedence order (the order, in which
methods are resolved against classes). For an object of class
"mongrel" info precedence returns:

::mongrel ::foobar ::foo ::bar ::geek ::xotcl::Object

Since xotcl is a dynamic language, it is possible to change at runtime
the inheritance structure (e.g changing classes/superclasses, provide
mixins classes etc). If one would hard-code the class in a call of a
same-named method (like BaseClass.init instead of "next") the
semantics are maybe not what one would expect when the class structure
changes. So, this implicit precedence order is quite important.

-gn
First  |  Prev  | 
Pages: 1 2
Prev: Is it possible to specify in TclOO classes a kinds of operators? (e.g. == or "eq")
Next: Making a Scrollable Widget