Re: refcount checking in add_interface

[Darin Adler <darin eazel com>]

on 3/29/00 4:16 AM, Nat Friedman at nat@helixcode.com wrote:

> Please add this check back.
> 
> Or, if you want to go a step further, you can enforce the actual
> invariant which matters; that is, after someone QI's for an interface,
> we must always give the same answer in the future.  The invariant is:
> 
> If QI (component, "interface") returns a valid interface, it must
> always return a valid interface.  If QI (component, "interface")
> returns NIL, it must always return NIL.
> 
> So, to enforce the invariant, we can keep a hash table of interfaces
> which have been requested, and store whether or not we returned an
> interface.  Then, in the future, we bail if the component implementor
> tries to change the list of supported interfaces in a way which the
> user might be able to notice.
> 
> Actually, it's worse than that, because you might be aggregating two
> objects which have *both* already been exposed.  So at aggregation
> time you also have to check the hash tables against each other and
> make sure there's no mismatch.  Then you have to merge them.
> 
> This gets pathologically complex.  Which is why we have that simple,
> naive check in there.

It's slightly worse than that!

If we want to make add_interface work in the case where the two ref counts
are not both == 1, by adding a more-correct check (like the hash table thing
you suggested above), we have to add a bit of code to look at the ref
counts. The current code just drops one of the tow ref counts on the floor.
This is only OK if it's known to be == 1.

So if we don't add the check back and instead add a check for the "actual
invariant that matters", then we'll have to add a little ref count merge.

    -- Darin