No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] TIP #257: Object Orientation for Tcl
From: Gustaf Neumann <neumann_at_wu-wien.ac.at>
Date: Wed, 28 Sep 2005 19:20:41 +0200
Donal K. Fellows schrieb:
> 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
i was not talking about the c api at all here. i was refering to the
xotcl methods
implemented in C (e.g. create, destroy, class, forward, mixin ...) being
placed
into a method repository (e.g. a namespace) maybe called ::xotcl::objcmds
and ::xotcl::classcmds and then one can do e.g.
oo::class ::xotcl::Object -import public ::xotcl::objcmds::*
oo::class ::xotcl::Class -superclass ::xotcl::Object -import public
::xotcl::classcmds::*
::xotcl::Class class ::xotcl::Object
while people proposing other OO-Systems can import stuff
private/public to any
kind of class hierarchy they want. In reality this will be more
complicated, but
you get the idea.
>
>> 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.
hmm, what is a metadata manipulator? i was talking about more primitive
c-level constructs which could help to make tcl (and its oo parts) more
consistent. Read method repository (MR) as hash table of command pointer
and data repository (DR) as hash table of variables. i would like to see a
consitent interface to these as well in ca on the tcl layer and having these
compontents in a better composable way. This would provide a much
better basis for multiple OOs and a better integration with current tcl
core (both ways)
>
>> 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.
This can be solved by defining e.g. SnitClass having everything
private except what it wants to publish.
>> 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.
i have to figure out, where this is...
>
> 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?
as kristoffer pointed out, there is only one move, so there is no
ambiguity. In general the precedence order is
per-object-mixins per-class-mixins self-procs class-hierarchy
The introspection command for this is
D info precedence
-gustaf
>
> Donal.
Date: Wed, 28 Sep 2005 19:20:41 +0200
Donal K. Fellows schrieb:
> 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
i was not talking about the c api at all here. i was refering to the
xotcl methods
implemented in C (e.g. create, destroy, class, forward, mixin ...) being
placed
into a method repository (e.g. a namespace) maybe called ::xotcl::objcmds
and ::xotcl::classcmds and then one can do e.g.
oo::class ::xotcl::Object -import public ::xotcl::objcmds::*
oo::class ::xotcl::Class -superclass ::xotcl::Object -import public
::xotcl::classcmds::*
::xotcl::Class class ::xotcl::Object
while people proposing other OO-Systems can import stuff
private/public to any
kind of class hierarchy they want. In reality this will be more
complicated, but
you get the idea.
>
>> 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.
hmm, what is a metadata manipulator? i was talking about more primitive
c-level constructs which could help to make tcl (and its oo parts) more
consistent. Read method repository (MR) as hash table of command pointer
and data repository (DR) as hash table of variables. i would like to see a
consitent interface to these as well in ca on the tcl layer and having these
compontents in a better composable way. This would provide a much
better basis for multiple OOs and a better integration with current tcl
core (both ways)
>
>> 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.
This can be solved by defining e.g. SnitClass having everything
private except what it wants to publish.
>> 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.
i have to figure out, where this is...
>
> 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?
as kristoffer pointed out, there is only one move, so there is no
ambiguity. In general the precedence order is
per-object-mixins per-class-mixins self-procs class-hierarchy
The introspection command for this is
D info precedence
-gustaf
>
> Donal.