Actually I disagree with the bug reporter that it should not be
autoreleased. The whole thing that prompted my original posting was
that the naming conventions of the DOM stuff do not fit in with the
Core Foundation and Cocoa conventions. For the DOM stuff it makes
sense to keep the 'official' class and method names and for objects
to be autoreleased. I do agree with the reporter that the
documentation needs improving.
3. All of the DOM classes inherit from DOMObject and that says it
conforms to NSCopying. I am guessing however that calling
[someDOMObject copy] is not going to produce a standalone copy of
many object types. As such, unless there is a 'cloneXXX' method
declared for the class such a standalone copy cannot be produced.
I think it's a bug that DOMObject says it conforms to NSCopying.
None of the DOMObject subclasses are copyable with the "copy" method.
What about things like hash and isEqual? Are these purely based on
the pointer value, or are they trying to be smart (i.e based on the
contents of the object)? I ask this as I am currently storing some
DOMNodes in an NSSet and my current code relies on the fact that each
node in the DOM is considered to not be equal to any other. Is this a
valid assumption (both now and into the future)?
Matt
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
