- From: David Vest <davve@opera.com>
- Date: Fri, 10 Mar 2006 13:28:43 +0100
- To: Chris Lilley <chris@w3.org>
- CC: www-svg@w3.org
Chris Lilley wrote: > On Friday, March 10, 2006, 10:12:54 AM, David wrote: > > DV> Jonathan Watt wrote: > >>> http://jwatt.org/svg/tests/transform-dom.svg > > DV> I think you have a bug in your test-case, it reads items from > baseVal DV> both times, and not from baseVal_2 in the second case as > probably was DV> the intention. > > DV> Here at Opera, there have been discussion around this topic also, > and DV> recent opera builds does not have the semantics you describe. > Currently DV> we throw away all objects relating to a certain object > meaning that all DV> equality between objects in your test-case would > be false. > > DV> Any formal clarification on this matter would be appreciated. > > > We will discuss it in the Working Group, and i have already contacted > jwatt with a view to including his test, or one derived from it, in > the test suite. > > Can you explain your rationale for throwing away objects rather than > reusing them? Is it more efficient to have the objects be immutable, > for instance, and does that mitigate the efficiency lost by object > creation and disposal? Perhaps a bit disappointing but the current rationale is that it gives easier implementation and verification in lack of a clear specification in that area. If we have an attribute, in this case 'transform', and extracts objects from it, all those objects are linked back to the attribute they came from. If the attribute changes (set by string), all objects originating from that attribute are released. The alternative is to special-case list-handling (like we have done in the past) and not recreate the list when set from string (just empty it and fill it again). We are open to adapt this behavior to the consensus reached here. On to the efficiency issues. I think mixing DOM Core (setAttribute) with SVG DOM interfaces on the same attribute should be a rather uncommon use-case. Because of that, we have not considered efficiency as a priority. -- David Vest <davve@opera.com>
Received on Friday, 10 March 2006 12:31:05 UTC