But that's only because Apple unwisely spent the money to develop
the accessors and conveniences in Objective-C rather than go with
the better Carbon design.
No it's not. I has very little to do with accessors and
conveniences, and nearly everything to do with design.
Well, I didn't explicitly state 'design' but thought it implicit in
"the notion of a system wide root object and more rigorously
enforced inheritance policy". But yes, it is a critical element,
and yes, the Carbon team were/are effectively starved of the kind of
resources and encouragement that allows them to do much design.
Specifically, there still aren't enough capabilities in the so-
called polymorpism of CFTypeRefs to enable the class-like
inheritance that would permit a unified UI model shared between
Carbon and Cocoa. Not to mention lack of support for archiving
anything except the plist basics in CoreFoundation. The fact that
HIViews were largely in place in 10.2 speaks volumes about how the
team accomplished more with less. Essentially putting the
Cocoamites to shame for both productivity and succinctness of
expression.
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
And what you suggest it to add so-called polymorpism to the CFRuntime.
And as we are here, we can also add some features like and dynamic
binding, and dynamic class generation. And maybe we can defined some
macros to help developpers to use those features using plain C. And we
can maybe find a new name for this style of C with object semantic?
And after that, Apple we be able to rewrite HIView and friends to
match the NSView model and conveniences.
Or maybe I miss your point ?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
