Where are the boundaries of Cocoa and how are the boundaries perceived ?

  • Do we all agree that Core Data, Foundation, and the Application Kit compose Cocoa ?  What other sub-frameworks should be considered part of Cocoa ?
      If I attempt to classify parts of Cocoa based on whether they are part of the Model, the View or the Controller subsystems in an MVC design, I see some interesting ambiguities.  For example, the Application Kit primarily contains objects that help you build Views, but some of the sub-systems within AppKit are themselves partitioned into separate Model, View, and Controller pieces as demonstrated by the text architecture and the document architecture.  Core Data is almost exclusively intended to support development of Models, right ?
      And where do KVC/KVO/Bindings fit into the picture?  Key Value Observing and bindings are pretty clearly Controller technologies, but Key Value Coding could arguably be most applicable to Models.  Where are KVO and Bindings really implemented ?  Some of it is in Foundation (categories on NSObject) and some is in AppKit.
      Foundation defies being grouped in any of the MVC subsystems.  It truly is a foundation upon which all of the MVC subsystems are built.
      To simplify my question, which of the following is considered part of Cocoa, and have I missed anything ?
      Exception Handling Framework
      Message Framework
      Address Book Framework
      Application Kit Framework
      Automator Framework
      Core Data Framework
      Foundation Framework
      iChat Instant Message Framework
      Preference Panes Framework
      Quartz Core Framework
      QuickTime Kit Framework
      Screen Saver Framework
      Security Foundation Framework
      Security Interface Framework
      Web Kit Objective-C Framework
      Sync Services Framework

      Within Cocoa, how is the MVC design expressed and can sub-frameworks of Cocoa be categorized according to MVC ?
  • On 1 Oct 2007, at 16:33, Erik Buck wrote:

    > Do we all agree that Core Data, Foundation, and the Application Kit
    > compose Cocoa ?  What other sub-frameworks should be considered
    > part of Cocoa ?

    IMHO Cocoa is everything in Cocoa.framework.

    There are other Objective-C frameworks on Mac OS X, but they are not,
    strictly speaking, Cocoa (though they do use ObjC).

    This seems like a sensible way to delimit the functionality of
    "Cocoa" per se, and matches what people (Apple in particular) do with
    Carbon.  i.e. Carbon is everything in Carbon.framework.  Other C APIs
    exist on the system, but they are not part of Carbon (though the
    implementation of Carbon---and indeed Cocoa---in many cases relies on
    them).

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • on 2007-10-01 11:33 AM, Erik Buck at <erik.buck...> wrote:

    > To simplify my question, which of the following is considered part of Cocoa,
    > and have I missed anything ?

    You left out OSAKit,framework, an Objective-C framework that re-implements
    some of the methods in NSAppleScript.framework and adds others. Although
    OSAKit.framework has never been documented, I am informed that it is
    preferred over NSAppleScript for some if not all of what NSAppleScript does.

    OSAKit presents a very interesting problem with respect to your question. It
    is not included in AppKit or Foundation and therefore isn't "Cocoa" from
    that point of view. Yet it at least optionally replaces NSAppleScript
    functionality with methods having the same name and function, and
    NSAppleScript is included in Foundation and therefore plainly is "Cocoa."

    So even those who narrowly define Cocoa as whatever is included in AppKit
    and Foundation (and Core Data), and nothing else, have to face the
    interesting puzzle of how to categorizie OSAKit.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • If it's an SPI, does it need classification? Developers aren't
    supposed to use undocumented functions in the system since they could
    change at any time and then your app will break.

    On Oct 1, 2007, at 3:35 PM, Bill Cheeseman wrote:

    > on 2007-10-01 11:33 AM, Erik Buck at <erik.buck...> wrote:
    >
    >> To simplify my question, which of the following is considered part
    >> of Cocoa,
    >> and have I missed anything ?
    >
    > You left out OSAKit,framework, an Objective-C framework that re-
    > implements
    > some of the methods in NSAppleScript.framework and adds others.
    > Although
    > OSAKit.framework has never been documented, I am informed that it is
    > preferred over NSAppleScript for some if not all of what
    > NSAppleScript does.
    >
    > OSAKit presents a very interesting problem with respect to your
    > question. It
    > is not included in AppKit or Foundation and therefore isn't "Cocoa"
    > from
    > that point of view. Yet it at least optionally replaces NSAppleScript
    > functionality with methods having the same name and function, and
    > NSAppleScript is included in Foundation and therefore plainly is
    > "Cocoa."
    >
    > So even those who narrowly define Cocoa as whatever is included in
    > AppKit
    > and Foundation (and Core Data), and nothing else, have to face the
    > interesting puzzle of how to categorizie OSAKit.
    >
    > --
    >
    > Bill Cheeseman - <bill...>
    > Quechee Software, Quechee, Vermont, USA
    > www.quecheesoftware.com
    >
    > PreFab Software - www.prefabsoftware.com
  • on 2007-10-01 4:47 PM, John Stiles at <JStiles...> wrote:

    > If it's an SPI, does it need classification? Developers aren't
    > supposed to use undocumented functions in the system since they could
    > change at any time and then your app will break.

    The OSAKit.framework headers are located in /System/Library/Frameworks. As I
    understand the way things work, that means it's public API and we're free to
    use it. Nothing in the headers suggests otherwise.

    If that isn't enough, there is an OSAPalette,palette file for Interface
    Builder located in /Developer/Extras/Palettes which you can add to your IB
    palette. It includes two views and two objects for OSAKit.framework.

    When I refer to OSAKit.framework as "undocumented," I mean that Apple hasn't
    published the formal developer documentation we are used to seeing for most
    AppKit and Foundation frameworks. Fortunately, the NSAppleScript
    documentation applies to those OSAKit methods that have the same names, and
    almost all of the OSAKit methods that don't have NSAppleScript analogs are
    named according to standard Cocoa AppKit conventions and should be very easy
    to figure out.

    In fact, OSAScriptView and OSAScriptController and their methods so closely
    conform to AppKit conventions (complete with IBAction methods and IBOutlet
    instance variables) that they make it virtually impossible not to count them
    as part of "Cocoa" in spirit and intent even though they aren't included in
    the Cocoa frameworks.

    --

    Bill Cheeseman - <bill...>
    Quechee Software, Quechee, Vermont, USA
    www.quecheesoftware.com

    PreFab Software - www.prefabsoftware.com
  • Cocoa is a high-level framework built on many underlying
    technologies. Even Foundation I don't think is a part of Cocoa. Case
    in point is I did some work on a Cocoa interface to another language
    a number of years ago. This language had its own library for data
    structures equivalent of Foundation. It was better to use the native
    arrays and collections rather than Foundation, only providing a
    little bit of Foundation to convert native arrays to NSArrays when
    calling a Cocoa function that required them.

    I think KVC and KVO are underlying technologies that have wider
    applicability than just Cocoa, similarly with Quartz and Quicktime.
    Just because Cocoa heavily uses these does not make them part of
    Cocoa. Cocoa relies on them, but they do not rely on Cocoa.

    As for MVC, often this is difficult to categorize in itself, but I
    had a concrete realization of something that was before intuitive –
    that Interface Builder deals in all of MVC. I think IB is part of
    Cocoa, It seems that something called Interface Builder would just
    deal in the V, but Cocoa bindings allow you to freeze-dry controller
    objects and I'm sure in simple applications, model objects can be
    stored as part of the nib as well (or just defaults). Maybe
    'Interface Builder' is a bit of a misnomer in this case, and I'm sure
    leads to confusion for those coming from other environments where you
    have a visual window painter, expecting it to just do V, when IB does
    at least VC and maybe all MVC.

    NSDocument is another interesting case. I used to think it was the
    root of the model, but now it seems like more a controller that
    references the model, and because you set it as a delegate for other
    view and controller objects.

    Ian

    On 02/10/2007, at 1:33 AM, Erik Buck wrote:

    > Do we all agree that Core Data, Foundation, and the Application Kit
    > compose Cocoa ?  What other sub-frameworks should be considered
    > part of Cocoa ?
    > If I attempt to classify parts of Cocoa based on whether they are
    > part of the Model, the View or the Controller subsystems in an MVC
    > design, I see some interesting ambiguities.  For example, the
    > Application Kit primarily contains objects that help you build
    > Views, but some of the sub-systems within AppKit are themselves
    > partitioned into separate Model, View, and Controller pieces as
    > demonstrated by the text architecture and the document
    > architecture.  Core Data is almost exclusively intended to support
    > development of Models, right ?
    > And where do KVC/KVO/Bindings fit into the picture?  Key Value
    > Observing and bindings are pretty clearly Controller technologies,
    > but Key Value Coding could arguably be most applicable to Models.
    > Where are KVO and Bindings really implemented ?  Some of it is in
    > Foundation (categories on NSObject) and some is in AppKit.
    > Foundation defies being grouped in any of the MVC subsystems.  It
    > truly is a foundation upon which all of the MVC subsystems are built.
    > To simplify my question, which of the following is considered
    > part of Cocoa, and have I missed anything ?
    > Exception Handling Framework
    > Message Framework
    > Address Book Framework
    > Application Kit Framework
    > Automator Framework
    > Core Data Framework
    > Foundation Framework
    > iChat Instant Message Framework
    > Preference Panes Framework
    > Quartz Core Framework
    > QuickTime Kit Framework
    > Screen Saver Framework
    > Security Foundation Framework
    > Security Interface Framework
    > Web Kit Objective-C Framework
    > Sync Services Framework
    >
    > Within Cocoa, how is the MVC design expressed and can sub-
    > frameworks of Cocoa be categorized according to MVC ?
    >
  • On Oct 1, 2007, at 8:13 PM, Bill Cheeseman wrote:

    >> If it's an SPI, does it need classification? Developers aren't
    >> supposed to use undocumented functions in the system since they could
    >> change at any time and then your app will break.
    >
    > The OSAKit.framework headers are located in /System/Library/
    > Frameworks. As I
    > understand the way things work, that means it's public API and we're
    > free to
    > use it. Nothing in the headers suggests otherwise.

    Yes, I think this is a fair statement. If it is in that location, it
    is intended to be public.

    If it isn't documented please visit Radar and file an enhancement
    request if you feel it should be. (this applies to anything of course)
  • I've read the other responses..

    From my perspective, I could say that it's anything our group
    documents :-)

    But more practically, It'd consider classifying anything that is
    prefixed with NS as part of Cocoa. That includes CoreData, AppKit, and
    Foundation). I'd probably exclude the prefs pane, or anything else
    that is related to a specific application.

    KVC and KVO (and KVV/KVB) are all Foundation technologies.  I'm not
    sure I'd classify them as controllers though...

    I'm also not sure that trying to squeeze all classes into model/view/
    controller is going to work very well.  For example, where would the
    URL Loading System go?

    Also, I'd probably consider including any technology that can't be
    used directly by carbon (without some sort of bridging Cocoa-view).
  • On Oct 2, 2007, at 1:43 AM, Scott Anguish wrote:

    > KVC and KVO (and KVV/KVB) are all Foundation technologies.  I'm not
    > sure I'd classify them as controllers though...

    Whoops, it was pointed out to me that KVV and KVB are actually AppKit
    technologies.
  • Actually, you are right, both AppKit and Foundation are part of
    Cocoa. I'd clarify my previous post to say that I used the native
    libraries of the language in question for collections (so the
    heuristic was wrong). Thus it covered all of AppKit, but I did not
    have to include much of Foundation.

    Ian

    On 02/10/2007, at 4:47 PM, Scott Anguish wrote:

    >
    > On Oct 2, 2007, at 1:43 AM, Scott Anguish wrote:
    >
    >> KVC and KVO (and KVV/KVB) are all Foundation technologies.  I'm
    >> not sure I'd classify them as controllers though...
    >
    > Whoops, it was pointed out to me that KVV and KVB are actually
    > AppKit technologies.
    >
  • Scott Anguish <scott...> wrote:
    On Oct 2, 2007, at 1:43 AM, Scott Anguish wrote:

    > KVC and KVO (and KVV/KVB) are all Foundation technologies. I'm not
    > sure I'd classify them as controllers though...

    Whoops, it was pointed out to me that KVV and KVB are actually AppKit
    technologies.



      In my opinion, KVC is primarily a naming convention and methods (added as a category on NSObject) that enables access to "attributes" by name regardless of whether the attributes are stored as instance variables, calculated, or loaded from an external source.  The fact that appropriately named methods are called when attributes are accessed is in some respects just a (very important) implementation detail.  KVC is useful in any part of MVC.
      KVO is arguably a Model layer technology because management of dependant keys is a Model implementation detail, and automatic notification of changes to the Model is a traditional element of the MVC design going all the way back to Small-talk in the 1970s.  I say dependant keys are a Model detail because which keys depend on other keys is best known only by the Model, and the Model could be changed to work differently with different dependencies and neither the View nor the Controller would be affected.
      On the other hand, the KVO automatic notification of attribute changes exists so that Controllers and Views are kept up to date with the Model.  In that respect, KVO starts to look like a Controller technology.  NSController, which certainly is part of the Controller, relies on KVO for its implementation.  If KVO is part of the Model then NSController is tightly coupled to the Model’s implementation which may not be desirable, but I suspect is normal.
  • There's also PDFKit.
    It's a good Cocoa "citizen."

    -Joel


    ____________________________________________________________________________________
    Yahoo! oneSearch: Finally, mobile search
    that gives answers, not web links.
    http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
  • On Oct 1, 2007, at 8:33 AM, Erik Buck wrote:

    > Do we all agree that Core Data, Foundation, and the Application Kit
    > compose Cocoa ?  What other sub-frameworks should be considered part
    > of Cocoa ?

    I would say that "Cocoa" is on the way from being a noun to becoming
    an adjective.  Back around the days of 10.0, Cocoa was the AppKit +
    Foundation.  Today, I would describe any of the frameworks you listed
    as being a Cocoa framework.

    -jcr
previous month october 2007 next month
MTWTFSS
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
Go to today