On Apr 19, 2006, at 3:13 PM, Maciej Stachowiak wrote:
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.
I don't believe this to be true, though it would be more work.
Apple introduced major version numbers in frameworks years ago and
has yet to actually use them for anything as far as I can tell (i.e.,
AppKit has been stuck at 'C' for a long long time now). This is the
sort of incompatible API change that could be made with a major
framework version. If the 10.5 SDK was AppKit.framework/Versions/D
and the 10.4 stayed as C, then the API change would be doable (with
10.5 shipping both C and D, C with the extra autorelease, D with the
correct semantics according to the rules).
I imagine this would be moderately difficult to do, but it is by
no means impossible. The effort vs. gain argument is a whole
different discussion, though, each time there is an exception to the
rules, the utility of the rules is diminished and everyone's lives
get a tiny bit harder.
In this particular case, there is the extra issue that -
autorelease isn't a terribly scalable pattern. If someone were
creating a large DOM tree, they'd pay a bigger NSAutoreleasePool tax
than they should need to.
At any rate, the documentation needs to be fixed :)
-tim
_______________________________________________
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
