No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] TIP #257: Object Orientation for Tcl
From: Donal K. Fellows <donal.k.fellows_at_manchester.ac.uk>
Date: Wed, 28 Sep 2005 16:49:01 +0100
Gustaf Neumann wrote:
> a) a more radical approach is to move all c-level commands out of
> object and class into one or more method repositories (similar to
> namespaces, but just a hash table containing for commands) and
> let the object system designer link these (private/public, if
> necessary) into the base classes of an object system. One can
> design a SnitClass or an XOTcl class or lsay a Java-kind class
> quite freely, and it provides room for incremental improvement
> without harming others.
The TIP is (totally!) light on C-level API, largely because I've no idea
what needs to go there. I'd even be happy (personally speaking) with an
OO system that did not provide any C-level API at all. Other people will
probably disagree. :-D
> b) We have discussed splitting xotcl classes into smaller components
> about two years ago. We did not do this mostly since xotcl users
> would most likely use Obect and Class as it is today.
[...]
> Having said this, i am certainly not sure that "define" leads
> the right way by moving the methods to manipulate the MR
> to the top.
Having the metadata manipulators outside the primary object hierarchy is
pretty much a requirement, and it comes from what's needed for
supporting multiple OO "looks and feels" on top. Whether it is a single
command is quite negotiable as is the precise name of the command(s) of
course.
> c) the concern with "clean interfaces" is certainly valid but addresses
> not only the number of methods, but as well orthogonality
> (so, define is neither orthogonal with tcl or xotcl).
I admit it; I don't treat orthogonality as holy. It's nice, but it's not
the only goal I have. :-)
[...]
> The TIP writers did not like the fact that general functionality
> is introduced in xotcl from Object (as it is in Ruby or Smalltalk
> or many other OO languages). I never found this a problem
> in real applications. i rather see problems with some low-level
> stuff, when it is not this way, when classes are destroyed, objects
> are reclassed, etc. I would feel better, when Object, Class are
> xtocl-like and and we provide some protection schemes through
> subclasses.
Again, that's driven by supporting other OO systems too.
> I am not going to repeat all earlier discussions here. Is it OK to
> send improvement proposals for the current TIP here, leaving
> aside this bigger issues?
The best place to discuss things is really the tcl-core mailing list.
BTW, I was wondering what happens when you do this in XOTcl (ignoring
the syntax for now):
class A derived from Object
defines instproc foo
class B derived from A
defines instproc bar
class C derived from Object
defines instprocs foo, bar and move
object D is a C with B mixed in
call: D foo
call: D move
Which implementation of foo gets called first? Which implementation of
move gets called first?
Donal.
Date: Wed, 28 Sep 2005 16:49:01 +0100
Gustaf Neumann wrote:
> a) a more radical approach is to move all c-level commands out of
> object and class into one or more method repositories (similar to
> namespaces, but just a hash table containing for commands) and
> let the object system designer link these (private/public, if
> necessary) into the base classes of an object system. One can
> design a SnitClass or an XOTcl class or lsay a Java-kind class
> quite freely, and it provides room for incremental improvement
> without harming others.
The TIP is (totally!) light on C-level API, largely because I've no idea
what needs to go there. I'd even be happy (personally speaking) with an
OO system that did not provide any C-level API at all. Other people will
probably disagree. :-D
> b) We have discussed splitting xotcl classes into smaller components
> about two years ago. We did not do this mostly since xotcl users
> would most likely use Obect and Class as it is today.
[...]
> Having said this, i am certainly not sure that "define" leads
> the right way by moving the methods to manipulate the MR
> to the top.
Having the metadata manipulators outside the primary object hierarchy is
pretty much a requirement, and it comes from what's needed for
supporting multiple OO "looks and feels" on top. Whether it is a single
command is quite negotiable as is the precise name of the command(s) of
course.
> c) the concern with "clean interfaces" is certainly valid but addresses
> not only the number of methods, but as well orthogonality
> (so, define is neither orthogonal with tcl or xotcl).
I admit it; I don't treat orthogonality as holy. It's nice, but it's not
the only goal I have. :-)
[...]
> The TIP writers did not like the fact that general functionality
> is introduced in xotcl from Object (as it is in Ruby or Smalltalk
> or many other OO languages). I never found this a problem
> in real applications. i rather see problems with some low-level
> stuff, when it is not this way, when classes are destroyed, objects
> are reclassed, etc. I would feel better, when Object, Class are
> xtocl-like and and we provide some protection schemes through
> subclasses.
Again, that's driven by supporting other OO systems too.
> I am not going to repeat all earlier discussions here. Is it OK to
> send improvement proposals for the current TIP here, leaving
> aside this bigger issues?
The best place to discuss things is really the tcl-core mailing list.
BTW, I was wondering what happens when you do this in XOTcl (ignoring
the syntax for now):
class A derived from Object
defines instproc foo
class B derived from A
defines instproc bar
class C derived from Object
defines instprocs foo, bar and move
object D is a C with B mixed in
call: D foo
call: D move
Which implementation of foo gets called first? Which implementation of
move gets called first?
Donal.