On 3/23/14 2:21 AM, Jim Blandy wrote:
See my slightly longer explanation in the previous message. The
advantage over passing true for ownsWeak is that my proposed API is
completely deterministic.
I'm not sure I follow The current setup in the observer service is
also completely determinis
On 03/22/2014 10:51 PM, Boris Zbarsky wrote:
Or put another way, how does this proposal differ from the already
existing ownsWeak argument of nsIObserverService.addObserver that was
discussed earlier in this thread?
See my slightly longer explanation in the previous message. The
advantage over
On 03/22/2014 10:43 PM, K. Gadd wrote:
> I'm confused about how this would work. who's observing what? How can
> obj be collected if you're passing it as an argument? This looks like
> a synchronous property set passed through an unnecessary intermediary.
Sorry, my code example was confusingly in
On 3/23/14 1:38 AM, Jim Blandy wrote:
For example, suppose we had:
observerService.addSettingObserver(obj, "dirty", true)
which promises to set obj's 'dirty' property to true. If obj is
collected, this observer can obviously be dropped.
How do we know when "obj" is collected?
Or put ano
On 03/19/2014 04:39 PM, Kyle Huey wrote:
Short of not implementing things in JS, what ideas do people have for
fixing these issues? We have some ideas of how to add helpers to
scope these things to the lifetime of the window (perhaps by adding an
API that returns a promise that is resolved at in
Perhaps in some cases weaker, more manageable mechanisms than
full-powered observers and listeners could be sufficient.
For example, one approach which gets you the right cleanup behavior
without exposing GC, is to have special-case observers which can be
easily proven to be safe to drop. For
On Sat, Mar 22, 2014 at 8:26 AM, K. Gadd wrote:
> I mentioned self-hosting to illustrate the need for weak references:
> It's fine that the JS
> environment has no weak reference alternative as long as all the 'hard
> stuff' is
> written in C++, but it seems as if there are reasons to move and
>
I implied that the popups are using the parent document to communicate
with each other (I thought I stated this?). If you retain the parent
document after it is closed in order to keep the child documents
working, now you have a cycle that requires a cycle collector (parent
-> children, children ->
8 matches
Mail list logo
