W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Web DOM Core feedback

From: Robert O'Callahan <robert@ocallahan.org>
Date: Fri, 14 Jan 2011 23:53:34 +1300
Message-ID: <AANLkTim4ZKkJ+yARJgQcZ7kA_XKha9Y9MBwhNxHswZBY@mail.gmail.com>
On Fri, Jan 14, 2011 at 11:41 PM, James Graham <jgraham at opera.com> wrote:

> On 01/13/2011 10:05 PM, Aryeh Gregor wrote:
>
>  There are a bunch of places where it says "When invoked with the same
>> argument the same NodeList object may be returned as returned by an
>> earlier call."  Shouldn't this be either required or prohibited in any
>> given case, not left undefined?
>>
>
> It seems like making this a requirement would interact badly with GC e.g.
> if I have some call that produces a huge NodeList that is then not
> referenced, I don't want to keep it around just in case some future script
> returns the same NodeList. On the other hand, there are scripts that put
> calls returning identical NodeLists in inner loops. In these cases not
> recreating the object every time is a big performance win.
>

The usual trick here is to weakly reference the cached NodeList. So if the
script holds onto a reference, then future calls will return that NodeList,
but if the script does not hold onto a reference, it can be GCed and future
calls will return a different NodeList. Then the spec can say that the same
NodeList will be returned, and that implementation satisfies the spec since
a script can't tell that the NodeList has changed without holding onto a
reference to the old NodeList.

... except I guess it can, because it could set expando properties on the
old NodeList and check for their presence later. Sigh.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
Received on Friday, 14 January 2011 02:53:34 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC