Oh, yes, thank you very much for bringing up the issue of threads!<div><br></div><div>I have to mention that they are not thread-safe.  The CL definition does not say whether hash tables are thread-safe since the CL definition has no thread concept.  CCL hash tables are thread-safe.<div>

<br></div><div>Right now, they aren&#39;t CLOS instances at all.  It was sort of a little pedagogical point of the exercise that an abstraction doesn&#39;t have to be a CLOS object.  This is part of my whole claim that CLOS, unlike, say, CLU, isn&#39;t trying to be an encapsulation mechanism.  If you want encapsulation, that&#39;s what packages are for.  Java tries to both and ends up with baroque rules about how &quot;protected&quot; interacts with &quot;in different packages&quot;.</div>

<div><br></div><div>But Fare pointed out to me that being able to add generic functions specialized on these would be a good thing.  This would mean making them use CLOS not for encapsulation but for genericty.</div><div>

<br></div><div>So maybe there could be a subclass that did the locking.  Java&#39;s new collection library also provides basic non-thread-safe collections, and then thread-safe ones built upon them.  Thread-safety costs.  I really ought to measure that, though.</div>

</div>