Simon Fraser <[EMAIL PROTECTED]> writes:
>> Ok, that brings me around to my original comment: why is this
>> a hand-rolled weak reference?
>
>Using a strong reference could introduce cycles. Ownership of editor
>looks something like:
>
>Compser (now):
> nsEditor <- nsEditorShell <- nsEditorBoxObject <- frames <- nsPresShell....
>So if editor starts holding on to something that indirectly
>also holds onto pres shells etc, we might end up with a long cycle.
>
>Strong refs should *only* be used where you really want an owning
>ref to something. If the editor outlives the view manager (perish the
>thought), then something is really wrong elsewhere.
Ok, right. I understand that - in some instances we need weak
references to avoid needing some form of GoAway() method to force releases
(and make it possible for destructors to be called). (This is one of the
downsides of COM and reference counting.) My question wasn't answered,
though: why are we hand-rolling a weak reference? I'm guessing that the
answer is "we're really really sure that the referenced thing (viewmanager)
could never go away on us".
A) I don't like assumptions like that (not that the fact that I
don't like it means anything)
B) We have a mechanism for dealing with weak references "correctly"
C) If there's an assumption like that, it _REALLY_ should be
commented!!!!
Here's something interesting (though perhaps not relevant, since I'm not
100% sure of the relationship between a PresShell and a ViewManager): the
viewmanager is gotten from the PresShell (which we have a weak reference
to via a real weak reference interface). Later, in EndUpdateViewBatch(),
we QueryReferant the presshell, and handle it not being there (though we
don't set mPresShellWeak to NULL - not a problem). Then we use the
viewmanager pointer, which we got from the PresShell - which apparently may
no longer exist. Now, it may be that the PresShell can't really go
away either, or that the view manager returned by the PresShell is still
valid even if the PresShell dies. (Probably.)
I guess the real point I'm trying to make here is that people need to be
more explicit (either with code (weak refs) or commments) about what the
real interfaces and assumptions are. And these assumptions may need to be
documented both in the consumer and the producer, so someone doesn't
change something so as to violate the assumptions. I, for example, was
tracking down a general problem with use of GetViewManager(), and happened
to be confused by this because I don't know the assumptions of an nsEditor
or PresShell.
Thanks for the comments. So, should we change ViewManager to inherit from
nsSupportsWeakReference (ala
http://www.mozilla.org/projects/xpcom/weak_references.html) or just comment
the usage?
If I had been designing XPCOM, I might have been tempted to force all
classes to support weak references. You never know when someone you hold a
(possibly indirect) reference to (and which may have been created after
your class) might produce a cycle. If you don't inherit from
nsSupportsWeakReference, then people may be forced to resort to tricks, or
recoding your class (which is what (XP)COM is supposed to avoid).
--
Randell Jesup, Worldgate Communications, ex-Scala, ex-Amiga OS team
('88-94) [EMAIL PROTECTED]
