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.
And what you suggest it to add so-called polymorpism to the CFRuntime.
Well, if you followed my posts from May, and post-non-announcement of
2007, you will see that I suggested:
• Upgrading of CFTypes to coordinate with XML Data types + OSType
CFNumber type
• Modernization/adaption of the AppleEvent object model (i.e. the
object, query, and resolution facilities) to be a much tighter and
lower level integration with CFTypes
• Working from the above to be as compatible as possible with NSObject.
And as we are here, we can also add some features like and dynamic
binding, and dynamic class generation.
In my sketch implementation of the above, I was getting really close
to dynamic AppleEvent class generation (property generation is almost
a given). The basics were done in CoreFoundation with of course the UI
objects done with the standard HIToolbox widgets. With the arrival of
runtime sdef loading in Leopard, and the lowering of AppleEvents to
CoreServices the task is considerably eased. That is, a scriptable
Carbon application with no aete. My design needs revision to handle
classes better but it's good enough for proof of concept. BTW, I did
this in C, but both Apple and Marco Piovanelli preceded my efforts by
many years with implementations in C++.
The way I figure it, there's no logical reason why AppleEvent objects
can't actually be CFType describable and vice versa. For instance,
currently the DescTypes for CFArrayRef, CFStringRef,
CFMutableDictionaryRef, etc. are way up in Carbon. But they're just
UInt32s. The base AppleEvent types (with the exception of files) are
essentially the plist types, so at the fundamental level, the job's
already done. All that has to be done is move the registry definitions
down to CoreFoundation level.
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 ?
I know you're an excellent programmer because you have consistently
illustrated more than passing knowledge in a wide range of
technologies in your posts. Assignments for you to consider are:
CFPath (Quinn from Apple has a starting point in SC sample code),
CFXPath, and CFSQLite. These will be done in C with typical CF
interfaces and naming conventions.
Thanks,
Philip Aker
echo email@hidden@nl | tr a-z@. p-za-o.@
_______________________________________________
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
