ANNOUNCE: BOOP, a basic all-Tcl object-oriented framework
John Buckman
object oriented helper that gives you tcl objects, member functions,
object-local storage, memory cleanup all with one tiny ::boop function of
less than 100 lines of tcl.
For more BOOP info see: http://mini.net/tcl/8296
The aim of BOOP is to provide a very simple object oriented programming
helper in Tcl, without doing anything fancy or complicated, that requires
a learning curve or causes other problems. If you want a full OOP Tcl
environment, go for "incr Tcl" or "stoop".
I tried to use stoop, but ran into a number of problems, namely: 1) it
clashes badly with the TclPro debugger, 2) member functions seem to be
wrapped in a silent catch{} statement, making debugging buggy member
functions very difficult and 3) no array support. Incr Tcl was too huge
for my needs, and I wanted an all Tcl-solution, with a minimal learning
curve for my coworkers. I didn't want to write OOPy Tcl code that no-one
else would understand.
In short, I wanted a Tcl OOP helper to be as simple, transparent as
possible, and not to muck with built in commands or cause problems with
the TclPro debugger or confuse people reading my OOPy code.
Here is an example of using a boop object:
# A simple member function:
proc test::example {this arg} {
# local member variable
variable ${this}::x
variable ${this}::z
incr x
puts "I am $this, passed '$arg' and x is '$x' and z(y) is '$z(y)'"
}
# "test" is the class name, "myobject" is the local object name
boop test myobject
# using the object and member function
$myobject example "argument1"
$myobject example "argument2"
Boop automatically cleans up the object when it goes out of scope.
Jean-Luc Fontaine
>...
> I tried to use stoop, but ran into a number of problems, namely: 1) it
> clashes badly with the TclPro debugger, 2) member functions seem to be
> wrapped in a silent catch{} statement,
"seem"? That is simply not the case.
> making debugging buggy member
> functions very difficult and 3) no array support.
How to manage member arrays is clearly documented in stooop.
Jean-Luc (stooop author)
John Buckman
> > clashes badly with the TclPro debugger, 2) member functions seem to be
> > wrapped in a silent catch{} statement,
>
> "seem"? That is simply not the case.
Inside TclPro, an error in a stoop-enabled member function does not
cause an error while debugging. As you say, there is no catch{}
statement in stooop, thus the problem must be elsewhere in stooop --
perhaps redefined basic Tcl commands don't play nice inside the TclPro
debugger. When working with a large application, debugger support is
really helpful, and the fact that I couldn't get errors (or for that
matter, breakpoints) inside TclPro/stoop code made stooop harder to
work with. For people who don't use TclPro, I'm sure this issue with
stooop isn't a problem.
Also: inside TclPro, stooop would sometimes complain about a member
function being defined before the constructor was (when first loading
up the tcl code), but that error didn't happen when running w/o
TclPro.
> > making debugging buggy member
> > functions very difficult and 3) no array support.
>
> How to manage member arrays is clearly documented in stooop.
From the stooop docs:
"You simply cannot use a member array, as member data is already held
in an array. But you can use a global array, with a name specific to
the object, including the object identifier. Just make sure the array
is deleted in the destructor."
As I read that, stooop doesn't support arrays directly, but the
work-around is to use a global variable and then make sure you delete
it in the destructor. That's a work-around, and it does work. My
statement that stoop provides "no array support" is too strong (I'll
take it back), but perhaps you'll agree that arrays are not as richly
supported in stooop as lists and strings.
In my BOOP implementation, arrays are placed in the namespace of the
object, so that they're automatically destroyed with the object, and
the object is automatically destroyed when it goes out of scope.
There's no need to remember to clean things up (in BOOP,
constructors/destructors are optional, since namespaces are used to
clean up).
At any rate, I have no desire to get into a holy war about Tcl OO
libraries, as I really like a lot about stooop, and think it's a
valuable contribution. It just didn't do what I wanted, and nothing
else out there did, so I wrote my own thing, and decided to share it
in case others found it useful.
stooop does a lot more OO than BOOP does, and to do this, has to adopt
an architecture that changes more stuff inside Tcl (which is probably
what leads to conflicts with TclPro).
I really wanted automatic destruction of objects when they went out of
scope, which is something I don't believe stooop does (correct me if
I'm wrong). I'm using my BOOP class inside TclHttpd, a long-lived
process, so that any un-collected objects would eventually cause
memory bloat. With a multi-programmer team, anything I can do to make
sure that one programmer's single mistake doesn't bring down the
entire application is good.
Finally, this is a just a philosophical difference: I wanted an OO
extension that used the built-in Tcl mechanisms as much as possible
(because they're reliable and fast, and already do a fair amount of
OO) and didn't redefine any standard commands (or require {} around
large parts of my code) as that causes (in my experience) problems
with other apps and libs. stooop provides more OO features than BOOP
does, and thus has a different set of benefits and tradeoffs.
-john
Jean-Luc Fontaine
> > > clashes badly with the TclPro debugger, 2) member functions seem to be
> > > wrapped in a silent catch{} statement,
> >
> > "seem"? That is simply not the case.
>
> Inside TclPro, an error in a stoop-enabled member function does not
> cause an error while debugging. As you say, there is no catch{}
> statement in stooop, thus the problem must be elsewhere in stooop --
> perhaps redefined basic Tcl commands don't play nice inside the TclPro
> debugger. When working with a large application, debugger support is
> really helpful, and the fact that I couldn't get errors (or for that
> matter, breakpoints) inside TclPro/stoop code made stooop harder to
> work with. For people who don't use TclPro, I'm sure this issue with
> stooop isn't a problem.
Agreed. I have never tested TclPro, and I can understand that it may
have problems with stooop, or the other way around ;-). I may look
into it, but I personally do not feel the need for a debugger (maybe
because I haven't tried TclPro).
> Also: inside TclPro, stooop would sometimes complain about a member
> function being defined before the constructor was (when first loading
> up the tcl code), but that error didn't happen when running w/o
> TclPro.
>
> > > making debugging buggy member
> > > functions very difficult and 3) no array support.
> >
> > How to manage member arrays is clearly documented in stooop.
>
> From the stooop docs:
>
> "You simply cannot use a member array, as member data is already held
> in an array. But you can use a global array, with a name specific to
> the object, including the object identifier. Just make sure the array
> is deleted in the destructor."
>
> As I read that, stooop doesn't support arrays directly, but the
> work-around is to use a global variable and then make sure you delete
> it in the destructor. That's a work-around, and it does work. My
> statement that stoop provides "no array support" is too strong (I'll
> take it back), but perhaps you'll agree that arrays are not as richly
> supported in stooop as lists and strings.
I agree and I don't... In stooop, you can treat array members as data
members as in:
set ($this,array,index) value
in which case they are treated as any other data member, or use the
following documented method inside the class code:
variable ${this}array
set ${this}array(index) value
in which case you also have to free the array in the class destructor.
> In my BOOP implementation, arrays are placed in the namespace of the
> object,
As you can see above, the array also lies in the class namespace,
although the documentation erroneously qualifies it as "global": I
will fix that.
> so that they're automatically destroyed with the object, and
> the object is automatically destroyed when it goes out of scope.
> There's no need to remember to clean things up (in BOOP,
> constructors/destructors are optional, since namespaces are used to
> clean up).
>
> At any rate, I have no desire to get into a holy war about Tcl OO
> libraries, as I really like a lot about stooop, and think it's a
> valuable contribution. It just didn't do what I wanted, and nothing
> else out there did, so I wrote my own thing, and decided to share it
> in case others found it useful.
That is no problem and I welcome your contribution. I just wanted to
correct what I felt were incorrect statements on stooop.
Andreas Kupries
jo...@lyris.com (John Buckman) writes:
> I tried to use stoop, but ran into a number of problems, namely: 1) it
> clashes badly with the TclPro debugger, 2) member functions seem to be
Big caveat to all wishing to debug Tcl based OO packages (and code
using them) with the TclPro debugger and derivates [*].
The TclPro Debugger in all its incarnations currrently by default
_recognizes and instruments_ [incr Tcl] commands. This means that to
the debugger a 'class' command is [incr Tcl] and handled as such. If
the class command actually came from a different OO package and has a
different syntax bad things happen.
To disable this behaviour open the dialog "Project Settings" for the
project in question, switch to the tab "Instrumentation" and uncheck
the [Incr Tcl] check box in the lower right corner.
[*] Like ActiveState's Tcl Dev Kit Debugger.
--
Sincerely,
Andreas Kupries <akup...@shaw.ca>
Developer @ <http://www.activestate.com/>
Private <http://www.purl.org/NET/akupries/>
Join us at the Tenth Annual Tcl/Tk Conference <URL: http://wiki.tcl.tk/6274>
-------------------------------------------------------------------------------
}