[fitz-dev] Ideas for name contexts (atom repositories)

[Antony Courtney]

Hi Raph,

Thanks for taking the time to share your design ruminations with the 
rest of us; I hope we can help you think through some of the issues.

In your message you present 3 different alternatives for managing names 
(and some variations for alternatives 1 and 2).

However, unless I am missing something, (1) and (2) look to me like 
mechanisms for global string management in a library, whereas option (3) 
is really a clever implementation trick for callee-managed storage, for 
a particular ADT (dict's in this case).

But if we restrict our scope to the problem of callee-managed storage 
for a particular ADT, rather than the (much more difficult) problem of 
global storage management for a library, I'm not so sure that all of the 
reasons for rejecting alternatives (1) and (2) still apply.

What is the expected lifetime of dict's?  If it's expected to be 
relatively short or finite, then why not just have a per-dict intern 
table for the keys?

On the other hand, if the lifetime of a dict could be indeterminate, 
then of course you have to worry about leaking memory just as you did 
for option (1a).  But then why can't you use removal of a key from the 
dict as a basis for refcounting or gc of a per-dict intern table, 
without leaking the GC complexity across the API?

Or (even better) you could just have a single intern table shared by all 
live dict instances, and use explicit allocation or deallocation of 
dict's along with presence/absence of keys in all live dicts as a basis 
for GC or refcounting.  Again, this would look just like callee-managed 
storage of the names to the client of the dict API, and hence should 
isolate the client from the GC/ref-counting complexity.

What do you think?

	-antony

-- 
Antony Courtney
Grad. Student, Dept. of Computer Science, Yale University
antony at apocalypse.org          http://www.apocalypse.org/pub/u/antony