No registered users in community xowiki
in last 10 minutes
in last 10 minutes
Re: [Xotcl] TIP #257: Object Orientation for Tcl
From: Neil Madden <nem_at_cs.nott.ac.uk>
Date: Tue, 27 Sep 2005 02:04:53 +0100
Will Duquette wrote:
> The point of [define] is simply that we want to be able to
> create objects which have a limited set of subcommands. Note
> that there's a distinct difference between writing an OO-API
> using a particular OO-framework for other users of that
> framework, and writing an object-style API for general users,
> many of whom might not care about the OO-framework at all.
> In the first case, you want to include all of the OO-framework's
> bells and whistles, because you expect your users to want to
> take advantage of them. In the latter case, you want to keep
> the API simple, clean, and easily documented.
That's certainly a good goal.
>
> [define] lets us do both. With [define] "instproc" and its
> siblings aren't subcommands of our objects--but at the same time,
> "instproc" and its siblings are available to every user who
> cares about them.
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.:
class method myclass someproc {args} { ... }
object method myobj ...
object mixin myobj ...
This also somewhat reduces the need for self.method/method (or
instproc/proc) distinction. Likewise, you could also use it for the
script-style of define:
class define myclass {
method foo ...
method bar ...
}
where these are interpreted as [class method myclass ...] and not
[object method myclass ...].
It sort of clashes with previous XOTcl usage, where [class instproc]
means define an instproc on the object "class", but if we change the
name to "method" anyway then this is less of an issue. You could even
leave access to the methods using the form:
myclass class method someproc ...
myobj object method ...
which leaves only one top-level method in objects (two in classes). That
seems a bit more OO-y, but I don't know if it really adds much.
-- Neil
Date: Tue, 27 Sep 2005 02:04:53 +0100
Will Duquette wrote:
> The point of [define] is simply that we want to be able to
> create objects which have a limited set of subcommands. Note
> that there's a distinct difference between writing an OO-API
> using a particular OO-framework for other users of that
> framework, and writing an object-style API for general users,
> many of whom might not care about the OO-framework at all.
> In the first case, you want to include all of the OO-framework's
> bells and whistles, because you expect your users to want to
> take advantage of them. In the latter case, you want to keep
> the API simple, clean, and easily documented.
That's certainly a good goal.
>
> [define] lets us do both. With [define] "instproc" and its
> siblings aren't subcommands of our objects--but at the same time,
> "instproc" and its siblings are available to every user who
> cares about them.
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.:
class method myclass someproc {args} { ... }
object method myobj ...
object mixin myobj ...
This also somewhat reduces the need for self.method/method (or
instproc/proc) distinction. Likewise, you could also use it for the
script-style of define:
class define myclass {
method foo ...
method bar ...
}
where these are interpreted as [class method myclass ...] and not
[object method myclass ...].
It sort of clashes with previous XOTcl usage, where [class instproc]
means define an instproc on the object "class", but if we change the
name to "method" anyway then this is less of an issue. You could even
leave access to the methods using the form:
myclass class method someproc ...
myobj object method ...
which leaves only one top-level method in objects (two in classes). That
seems a bit more OO-y, but I don't know if it really adds much.
-- Neil