- From: <bugzilla@jessica.w3.org>
- Date: Wed, 29 Sep 2010 20:35:55 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10834 --- Comment #2 from Philip Taylor <excors@gmail.com> 2010-09-29 20:35:55 UTC --- Unless I'm significantly misunderstanding things: The fact that you can refer to the document through ownerDocument means there's already necessarily a reference - otherwise you couldn't refer to it. The implementation can't magically grab the object out of thin air when you access ownerDocument, it has to already have a chain of references to reach it. There's no reason for it to ever automatically turn into null, unless it was specifically implemented with a weak reference that intentionally turns into null at some possibly non-deterministic time when there's currently no strong references, and it shouldn't be implemented like that unless it's specified like that, and I don't think it's specified like that anywhere. What matters to the spec is simply that it is possible to access the document via ownerDocument, which means the document is not garbage (by the theoretical definition of garbage). It's a low-level implementation detail that the this-is-not-garbage status will be determined by the presence of references, and there's no reason for the spec to care about that specific implementation detail and not the billion other implementation details in a browser. Having the spec mention half a dozen places where there are strong references is also pointless when e.g. the entire ES5 spec seemingly doesn't mention garbage collection even once, so nothing explicitly defines that if you write "var d = e.ownerDocument;" you've got a strong reference at that point. It would only be meaningful if the reference graph (and root set) of the entire web platform was specified, otherwise there's just a few specified references dangling in a giant ocean of undefinedness. (Hypothetically you could have a null garbage collector that does nothing, or a future-predicting oracle (perhaps based on a log replay) that collects objects precisely after the last time you read them (even if there's still some references). Less hypothetically, you could have a fancy JITted browser that statically analyses the code to realise a script has an Element variable but only ever accesses tagName so it's free to collect all the other properties immediately, even though it looks like the script still has a reference to the Element.) -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 29 September 2010 20:35:58 UTC