ScriptInterpreter cache for domobjects (dangerous change?)

[Maciej Stachowiak]

On Friday, February 28, 2003, at 12:59  AM, David Faure wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 10 January 2003 22:53, Maciej Stachowiak wrote:
>> On Friday, January 10, 2003, at 01:43  AM, David Faure wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Friday 10 January 2003 00:47, David Faure wrote:
>>>> Now the whole domObjectPerDocument stuff also makes sense to me :)
>>>
>>> I just had a thought about this:
>>> why not store the (KJS::DOMNode->Dom::Node) dict in the
>>> KJS::DOMDocument,
>>> instead of storing a dict of dicts in the more global
>>> scriptinterpreter?
>>>
>>> This sounds more object-oriented than the "dict of dicts" to me, and
>>> possibly
>>> faster too, at least in the cases where we already have to find out 
>>> the
>>> KJS::DOMDocument anyway. (In other cases it's equivalent, 2 dict
>>> lookups
>>> in both cases).
>>>
>>> What do you think?
>>
>> Well, there is also a DOM object cache that is *not* per document,
>> however, for strictly temporary objects like events that we don't need
>> to be kept alive for the duration of the document.
>>
>> Other than that, the plan sounds fine to me. It's pretty hard to get 
>> at
>> a dom node from JavaScript without ever creating the KJS DOMDocument
>> wrapper.
>
> I'm seriously lacking the time to implement this :(
> Would you by any chance be able to make that change?
> (both in Safari and in KHTML - or in Safari and I'd do the merging 
> with KHTML)

Your plan seems OK, but dict of dicts seems equally OK to me, so I 
would prefer to fix bugs that actually affect things instead of working 
on this structural change. Perhaps you could reconsider whether the 
dict of dicts approach is good enough for now. If it's definitely not, 
then I'll try to schedule time to rework it, and see if I can do the 
merge to KHTML myself.

Regards,

Maciej