Dan Sugalski <[EMAIL PROTECTED]> wrote: > At 9:03 PM +0100 11/1/04, Leopold Toetsch wrote: >>We need more vtables. >> >>* INTVAL hash() >> >>To properly support Python, we need: >>- a hash PMC that isn't restricted to STRING* keys
> Works for me. We probably need to make sure that everything's in > place for keys to tag the individual key elements properly too. There is one entry in the hash structure: Hash_key_type key_type; That should suffice. I don't think, we should mix STRING and PMC keys in one hash - or only with care: a STRING "foo" and a String PMC "foo" hash to the same hash value. An Integer PMC C<1> and a STRING key "1" are different. >>* void finalize() >> >>We should separate finalize() from the destroy() vtable. > Any reason that the destroy entry's insufficient? That's what I'd > intended it to do, at least. These two have different usage patterns. destroy() is needed commonly to free memory. finalize() is currently needed to close file handles and clear active timer PMCs. > I can see thinking about changing the scheme we use to destroy > things, certainly (like, say, putting the pmcs that need destruction > in a queue, tagging them as having been queued, run the queue and > trigger the destroy method, tag them as having been destroyed, then > if they come up as dead in the next round of DOD assume they're > garbage), but I'm not sure we need to split finalization and > destruction. When we have objects with finalizers, we have to run the finalizers in order from most derived down the parent chain. So as you state, we've to defer destruction, store these objects with finalizers somewhere, sort them, run user code to finalize objects and so on. Doing that all in the destroy vtable is tedious especially, when user code is involved too. The finalize vtable is overridable, the destroy isn't. A split makes this functionality much cleaner. leo
