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: Tue, 27 Sep 2005 13:12:07 +0200
Will Duquette schrieb:
>
>>
>> OK. The essential thing being done here then is to break down the
>> grab-bag of methods defined in Class and Object into a bunch of
>> different interfaces, so that clients of an object don't have to
>> worry about a bunch of extra "proc" and "filter" etc methods that
>> have nothing to do with their problem domain. I can sympathise with
>> that. However, I'm not sure [define] is the right solution, as it
>> just creates another bag of methods elsewhere (somewhat like [info]
>> has become). We could simply change the methods to be class- methods
>> of [class] and [object] (i.e. procs that expect an explicit self
>> argument, rather than instance-methods). That way by default
>> objects don't get lots of public methods that aren't needed by
>> clients, but you can still do, e.g.:
>
First of all, i do not like having define as it is for various reasons.
But having define as
an extra command is for an xotcl person not such a horrible thing, as
long we have
(inst)forward, which can bring it back into business with a one-liner.
The other way
around is more complicated.
But still, i think this issue is more than a matter of taste:
here are a few arguments:
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.
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.
Roughly and abstractly speaking, an xotcl class differs from
an xotcl object by
- providing a method repository (MR) for its instances
- providing a life cycle management (LCM, factory with recycling)
for
its instances (create, alloc, configure, init, recreate,
destroy, dealloc)
An xotcl object contains a data repository (DR) with an optional
(from the
implementation point of view) method repository for itself.
Furthermore,
objects are commands (which is to some respect nice, but makes it
very hard to compete in speed with languages which have more
lightweight objects such as Java).
A simplified picture of xotcl looks as follows:
XOTclObject = Cmd + DR + MR(self)
XOTclClass = XOTclObject + LCM + MR(instances)
With mixins, a class can have multiple MRs for its instances, and
an object can have multiple MRs for self.
Through various recent TIPs, Tcl namespaces are
converging towards xotcl Objects. As Tcl provides data repositories
both through namespaces and arrays. I would like to see a
convergence here, providing
maybe multiple "views" to the same "data model" (in the MVC
terminology), allowing e.g. "array names" on namespaces/objects
or the data store methods (e.g. set, unset, trace, ...) as
overloadable methods on associative
arrays and to provide a uniform interface for defining
procs/methods/instprocs..., not having to use sometimes "proc",
other times "define method". This issue of having slim
interfaces continues certainly on the C level where different
implementation for this isses bloat the code and makes it hard for the
code to behave consistently.
Furthermore the bunch of info commands can
be reduced by specifying in the info command the MR explicitely
(using e.g. MR(method)), using e.g. one "info args", one rename
method etc. for all methods/procs/instprocs/commands.
It would be certainly interesting to have the aspects described
above
as first class entities on the tcl layer and to provide composition
functionalities for these similar to mixins for system designers.
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.
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). Providing
a smaller interface can be achieved through good composition
facilities (having the "right" superclasses, mixins) and
hiding/protection (don't show helper methods, define explicit
interfaces, making methods/variables private).
From earlier discussion about this TIP, i had the impression
that this discussion is as well about "system matters" vs.
"application matters".
when one introspects an object, to see application issues
(like submit, book, ...) rather than implementation nissues like
being able to lappend to
variables, etc. The point of view depends certainly on where
one is doing the introspection, on the object (info methods is
large) or on the class of the object with it instprocs. The
documentation will be in most cases more on the class than
on the object level, which will be a rather slick interface.
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.
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?
-gustaf
Date: Tue, 27 Sep 2005 13:12:07 +0200
Will Duquette schrieb:
>
>>
>> OK. The essential thing being done here then is to break down the
>> grab-bag of methods defined in Class and Object into a bunch of
>> different interfaces, so that clients of an object don't have to
>> worry about a bunch of extra "proc" and "filter" etc methods that
>> have nothing to do with their problem domain. I can sympathise with
>> that. However, I'm not sure [define] is the right solution, as it
>> just creates another bag of methods elsewhere (somewhat like [info]
>> has become). We could simply change the methods to be class- methods
>> of [class] and [object] (i.e. procs that expect an explicit self
>> argument, rather than instance-methods). That way by default
>> objects don't get lots of public methods that aren't needed by
>> clients, but you can still do, e.g.:
>
First of all, i do not like having define as it is for various reasons.
But having define as
an extra command is for an xotcl person not such a horrible thing, as
long we have
(inst)forward, which can bring it back into business with a one-liner.
The other way
around is more complicated.
But still, i think this issue is more than a matter of taste:
here are a few arguments:
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.
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.
Roughly and abstractly speaking, an xotcl class differs from
an xotcl object by
- providing a method repository (MR) for its instances
- providing a life cycle management (LCM, factory with recycling)
for
its instances (create, alloc, configure, init, recreate,
destroy, dealloc)
An xotcl object contains a data repository (DR) with an optional
(from the
implementation point of view) method repository for itself.
Furthermore,
objects are commands (which is to some respect nice, but makes it
very hard to compete in speed with languages which have more
lightweight objects such as Java).
A simplified picture of xotcl looks as follows:
XOTclObject = Cmd + DR + MR(self)
XOTclClass = XOTclObject + LCM + MR(instances)
With mixins, a class can have multiple MRs for its instances, and
an object can have multiple MRs for self.
Through various recent TIPs, Tcl namespaces are
converging towards xotcl Objects. As Tcl provides data repositories
both through namespaces and arrays. I would like to see a
convergence here, providing
maybe multiple "views" to the same "data model" (in the MVC
terminology), allowing e.g. "array names" on namespaces/objects
or the data store methods (e.g. set, unset, trace, ...) as
overloadable methods on associative
arrays and to provide a uniform interface for defining
procs/methods/instprocs..., not having to use sometimes "proc",
other times "define method". This issue of having slim
interfaces continues certainly on the C level where different
implementation for this isses bloat the code and makes it hard for the
code to behave consistently.
Furthermore the bunch of info commands can
be reduced by specifying in the info command the MR explicitely
(using e.g. MR(method)), using e.g. one "info args", one rename
method etc. for all methods/procs/instprocs/commands.
It would be certainly interesting to have the aspects described
above
as first class entities on the tcl layer and to provide composition
functionalities for these similar to mixins for system designers.
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.
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). Providing
a smaller interface can be achieved through good composition
facilities (having the "right" superclasses, mixins) and
hiding/protection (don't show helper methods, define explicit
interfaces, making methods/variables private).
From earlier discussion about this TIP, i had the impression
that this discussion is as well about "system matters" vs.
"application matters".
when one introspects an object, to see application issues
(like submit, book, ...) rather than implementation nissues like
being able to lappend to
variables, etc. The point of view depends certainly on where
one is doing the introspection, on the object (info methods is
large) or on the class of the object with it instprocs. The
documentation will be in most cases more on the class than
on the object level, which will be a rather slick interface.
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.
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?
-gustaf