- From: Patrick Mueller <pmuellr@muellerware.org>
- Date: Fri, 21 Aug 2009 11:41:03 -0400
Mike Wilson wrote: > Another thing: > >>From the proposal it seems it will be possible for the GlobalScript context > to keep references to objects (DOM, JS data, etc) private to pages, and vice > versa possible for pages to keep references to GlobalScript objects. This > also opens up for a new way for independent pages finding and keeping > references to each other's objects if they are somehow registered in the > GlobalScript. > > When reloading a page there is also the additional dimension of the > GlobalScript possibly holding references to objects both from the previous > and current incarnation of the Document. In a way it seems GlobalScript > usage will in practice merge the JS worlds of all participating pages, > potentially including those already navigated away from. > > What are your thoughts on this? You could either force people to clean up after themselves, or they'll just be accumulating (essentially) garbage. Or you could imagine for contexts that have "gone away" (windows closed), the references to objects in those contexts magically become null. The second approach requires something like Smalltalk's become: method, at the JS engine level. And then folks might want to start asking for weak references, etc. Slippery slope to hell. Another issue with the "merge of JS worlds", which by the way is something which is done explicitly, not implicitly, will lead to potential version mis-match issues. Two pages accessing the same space may have different expectations of the versions of code loaded in them. This could be mitigated by using a version number in the space name, but that leads to a nightmare if you have lots of these spaces, having to apply version numbering for every change to your code. Java developers have a similar problem they affectionately call "ClassLoader hell". -- Patrick Mueller - http://muellerware.org
Received on Friday, 21 August 2009 08:41:03 UTC