[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
- To: <us>
- Subject: padl-2.1 published
- From: Mark S. Miller <mark>
- Date: Sun, 20 Aug 89 16:28:15 PDT
This is the one with CadDocs, Necromancers, WeakTables, and
chicken-wire memory leakyness (because of its pre-alpha ancestry).
Necromancers & WeakTables are there to be used for garbage collection,
but are not so used yet.
I also bit the bullet and made isEqual & hashForEqual in Object into
DEFERRED_FUNC. This means that the compiler will reject any
subclasses of Object that do not define these to do something. This
is important in order for Sets and Tuples to be able to hold any kind
of Object. Sets and Tuples assume these objects are responsive to
these messages. In the process of getting the whole system to
recompile again, I found many that did not define these. In fixing
this, I realized that many of our classes properly have an EQ
semantics for equality, so, instead of reproducing the relevent code
everywhere, I have installed a subclass of Object in Object.hxx called
EQObject. Subclasses of EQObject inherit EQ behavior for these
As Dean would be quick to point out, EQObject should not be considered
a "type" distinction, but a mechanism for implementation sharing. As
such it is an abuse of inheritance. Despite my continual
protestations to the contrary, I find I am an inheritance abuser.
Well, the first step to a cure is acknowledging the problem. At least
I haven't yet moved on to the multiple stuff, but the more I abuse,
the less I find I still get that same thrill from single inheritance.
Michael, please look at what I've done to the padl-2.1 copy of the
Bomb package. I've given Problem an equality behavior based on
problemName & val. I've also made various test classes in
Bomb-test.cxx subclasses of EQObject instead of subclasses of Object.