No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] TIP #257: Object Orientation for Tcl
From: Kristoffer Lawson <setok_at_fishpool.com>
Date: Mon, 26 Sep 2005 22:25:58 +0300
On 26 Sep 2005, at 20:40, Jeff Hobbs wrote:
> I know that many on this list will be interested in the
> following TIP just propsed:
>
> TIP #257: Object Orientation for Tcl
> http://www.tcl.tk/cgi-bin/tct/tip/257
First, I want to say I'm very excited about this TIP. If this goes
into 8.5 I'd really like to see a big concentrated effort to get Tcl
back on the map. Even Ruby is getting more press than Tcl right now
and this needs to be changed. If Tcl includes an OO infrastructure
with it then that might help with the push. It is essential we do not
do this in a manner that says, "Me too", but to display the diversity
and the elegance and power of Tcl. Tcl is a command-oriented language
(instead of object-oriented), but that simple principle offers us
ways to extend it in all kinds of directions. When a new paradigm
appears, Tcl will be able to handle it too.
This is not Tcl going OO after many years of dilly-dallying, but
providing a sound foundation which supports a wide range of
extensions that have already existed. It's about making coders' lives
easier.
I do have some comments on the TIP (no surprises there):
* The description about filters at the top of the TIP is not
necessarily totally in line with XOTcl. Filters are not only about
deciding whether a method is called but can also manipulate the
message which is being passed. They can catch and do anything really.
* Mixins in XOTcl are classes which are dynamically mixed into the
normal object inheritance chain. The mixins based on the TIP seem to
be about mixing in procedures, which would be quite different.
* I disagree with the need for exported/non-exported methods. It adds
complexity and for what? How is method lookup solved? Can sub-classes
access non-exported methods? If not, wont that lead to problems for
extensions? If they are seen, can they be overridden, even by
accident, with public methods? Basically I see the whole business of
private/public as mostly a documentation issue. There could be a
mechanism in place for auto-generating docs on certain methods but
not on others, but with no actual separation between the two. I
believe Python follows this model to some extent. Convention versus
forcing.
Besides, any mechanism such as the one described can be implemented
by the use of filters. Filters offer much greater flexibility in this
respect and finer granularity. I've never actually felt the need for
public/protected/private/package.
* It is not true that XOTcl's creation mechanism makes it difficult
to do Tk-like option handling.
The -dash arguments (or methods) are called before the constructor.
The standard XOTcl way to do Tk-like options is to make the options
into so-called parameters. Parameters are basically instance
variables which have setter/getter methods attached to them. This
leads to Tk-like option handling:
Class Car -parameter {
{doors 5}
}
set myCar [Car new -doors 3]
* I disagree with not making constructors methods. This is something
I find to be a nuisance in Java. They act a bit like methods but
aren't really methods. So I can't use normal inheritance rules to
automatically get a constructor from a super-class. This is
especially annoying with Exceptions which are often nothing more than
a new classification and have no added functionality whatsoever. It
also means a completely new mechanism needs to be in place for
constructor introspection and manipulation. In XOTcl this is trivial
as the constructor is a method like anything else.
Objective C uses the init method as a constructor (by convention) and
does not cause problems. I've never heard of anyone trying to call
[init] on an XOTcl object again. It all sounds a bit like a case of
premature protection --- something which often bothers me. Protection
makes a system more complex and often is not really needed.
Protection hasn't ever been a theme in Tcl. Let the user and
developer decide.
* Destructors. Same thing. Why? Why have something which adds
complexity when a method can manage the same? With methods the
implementation can decide whether to use the destructors further up
(there might be cases when this is not desired), or in what order to
apply its own cleanup and super-class cleanup.
I do agree that a [destroy] command might be a good idea. In fact,
I'd go the whole way and stick it on the top level. I know [rename]
can manage the same, but it's not totally obvious and then we'd have
one mechanism that does the same for anything. Oh, and whatever the
destructor does, I do believe it should not be allowed to prevent
destruction of the object (unless the [destroy] command is manipulated).
* I agree with the class vs object method naming convention.
* Having instprocs named methods sounds like a good idea.
* What about child objects? XOTcl provides a mechanism where an
object can be created as a child of another. If the parent object is
destroyed, the child is automatically destroyed too. This is often
useful and provides an alternative for one common area helped by
garbage collection (as long as these child objects are never used
anywhere else).
/ http://www.fishpool.com/~setok/
Date: Mon, 26 Sep 2005 22:25:58 +0300
On 26 Sep 2005, at 20:40, Jeff Hobbs wrote:
> I know that many on this list will be interested in the
> following TIP just propsed:
>
> TIP #257: Object Orientation for Tcl
> http://www.tcl.tk/cgi-bin/tct/tip/257
First, I want to say I'm very excited about this TIP. If this goes
into 8.5 I'd really like to see a big concentrated effort to get Tcl
back on the map. Even Ruby is getting more press than Tcl right now
and this needs to be changed. If Tcl includes an OO infrastructure
with it then that might help with the push. It is essential we do not
do this in a manner that says, "Me too", but to display the diversity
and the elegance and power of Tcl. Tcl is a command-oriented language
(instead of object-oriented), but that simple principle offers us
ways to extend it in all kinds of directions. When a new paradigm
appears, Tcl will be able to handle it too.
This is not Tcl going OO after many years of dilly-dallying, but
providing a sound foundation which supports a wide range of
extensions that have already existed. It's about making coders' lives
easier.
I do have some comments on the TIP (no surprises there):
* The description about filters at the top of the TIP is not
necessarily totally in line with XOTcl. Filters are not only about
deciding whether a method is called but can also manipulate the
message which is being passed. They can catch and do anything really.
* Mixins in XOTcl are classes which are dynamically mixed into the
normal object inheritance chain. The mixins based on the TIP seem to
be about mixing in procedures, which would be quite different.
* I disagree with the need for exported/non-exported methods. It adds
complexity and for what? How is method lookup solved? Can sub-classes
access non-exported methods? If not, wont that lead to problems for
extensions? If they are seen, can they be overridden, even by
accident, with public methods? Basically I see the whole business of
private/public as mostly a documentation issue. There could be a
mechanism in place for auto-generating docs on certain methods but
not on others, but with no actual separation between the two. I
believe Python follows this model to some extent. Convention versus
forcing.
Besides, any mechanism such as the one described can be implemented
by the use of filters. Filters offer much greater flexibility in this
respect and finer granularity. I've never actually felt the need for
public/protected/private/package.
* It is not true that XOTcl's creation mechanism makes it difficult
to do Tk-like option handling.
The -dash arguments (or methods) are called before the constructor.
The standard XOTcl way to do Tk-like options is to make the options
into so-called parameters. Parameters are basically instance
variables which have setter/getter methods attached to them. This
leads to Tk-like option handling:
Class Car -parameter {
{doors 5}
}
set myCar [Car new -doors 3]
* I disagree with not making constructors methods. This is something
I find to be a nuisance in Java. They act a bit like methods but
aren't really methods. So I can't use normal inheritance rules to
automatically get a constructor from a super-class. This is
especially annoying with Exceptions which are often nothing more than
a new classification and have no added functionality whatsoever. It
also means a completely new mechanism needs to be in place for
constructor introspection and manipulation. In XOTcl this is trivial
as the constructor is a method like anything else.
Objective C uses the init method as a constructor (by convention) and
does not cause problems. I've never heard of anyone trying to call
[init] on an XOTcl object again. It all sounds a bit like a case of
premature protection --- something which often bothers me. Protection
makes a system more complex and often is not really needed.
Protection hasn't ever been a theme in Tcl. Let the user and
developer decide.
* Destructors. Same thing. Why? Why have something which adds
complexity when a method can manage the same? With methods the
implementation can decide whether to use the destructors further up
(there might be cases when this is not desired), or in what order to
apply its own cleanup and super-class cleanup.
I do agree that a [destroy] command might be a good idea. In fact,
I'd go the whole way and stick it on the top level. I know [rename]
can manage the same, but it's not totally obvious and then we'd have
one mechanism that does the same for anything. Oh, and whatever the
destructor does, I do believe it should not be allowed to prevent
destruction of the object (unless the [destroy] command is manipulated).
* I agree with the class vs object method naming convention.
* Having instprocs named methods sounds like a good idea.
* What about child objects? XOTcl provides a mechanism where an
object can be created as a child of another. If the parent object is
destroyed, the child is automatically destroyed too. This is often
useful and provides an alternative for one common area helped by
garbage collection (as long as these child objects are never used
anywhere else).
/ http://www.fishpool.com/~setok/