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.
I think it might have been good to do this in the first place
(there's no reason we couldn't apply CF / Cocoa conventions to the
existing DOM standard names - the DOM says nothing about ObjC
refcounting semantics) but now that we've shipped it's too late to
change, since it would cause leaks for existing clients.
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)?
It is based on pointer identity.
Regards,
Maciej
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
