Who Calls Accessors in Bookmarks?

  • I've been studying the Bookmarks example and trying to lift code for
    Drag and Drop in tables.  What I don't understand is why the document has a
    set of name-specific accessors for the array.  My code doesn't seem to need
    such.

        Furthermore, I don't understand how these accessors are getting called
    when "Add" and "Remove" buttons are clicked (yes, they trip breakpoints)
    since these are connected to the controller add/remove and I can't find any
    code or bindings that call the above named accessors.
  • On 8/30/07, Gordon Apple <ga...> wrote:
    > I've been studying the Bookmarks example and trying to lift code for
    > Drag and Drop in tables.

    Helps to give context on which example (or a link) but I am going to
    assume you are talking about
    <http://homepage.mac.com/mmalc/CocoaExamples/Bookmarks.zip>.

    > What I don't understand is why the document has a
    > set of name-specific accessors for the array.  My code doesn't seem to need
    > such.

    Why? Well likely as an example to show you how to support things like
    this in a way that allows your storage to be as you want (ignore the
    fact that the storage in this case is just a serialized mutable
    array).

    > Furthermore, I don't understand how these accessors are getting called
    > when "Add" and "Remove" buttons are clicked (yes, they trip breakpoints)
    > since these are connected to the controller add/remove and I can't find any
    > code or bindings that call the above named accessors.

    <file:///Developer/ADC%20Reference%20Library/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/AccessorConventions.html#//apple_ref/doc/uid/20002174>

    "You can also support to-many relationships by implementing the
    indexed accessor methods for those properties. These methods make it
    possible to support key-value coding for to-many relationships where
    the related objects aren't stored in an array. Implementing indexed
    accessors methods for a property makes that property indistinguishable
    from an array when using key-value coding methods.

    Supporting to-many relationships in this manner requires that your
    class implement two methods using the naming pattern -countOf<Key> and
    -objectIn<Key>AtIndex:. The -countOf<Key> method returns the number of
    objects in the to-many relationship as an unsigned integer. The
    -objectIn<Key>AtIndex: method returns the object at the specified
    index in the to-many relationship."

    ...

    "The key-value coding methods mutableArrayValueForKey: and
    mutableArrayValueForKeyPath: provide mutable access to a to-many
    relationship, regardless of the class used to model the relationship.

    In order to support these methods, your class must implement two
    additional methods for each of these keys:
    -insertObject:in<Key>AtIndex: and -removeObjectFrom<Key>AtIndex:. The
    -insertObject:in<Key>AtIndex: method is passed the object to insert,
    and an unsigned int that specifies the index where it should be
    inserted. The -removeObjectFrom<Key>AtIndex: method is passed an
    unsigned int value specifying the index of the object to be removed
    from the relationship. The example in Listing 6 shows the methods
    required to support mutableArrayValueForKey: for the to-many
    transactions property."

    -Shawn
  • On Aug 30, 2007, at 3:09 PM, Gordon Apple wrote:

    > I've been studying the Bookmarks example and trying to lift code
    > for
    > Drag and Drop in tables.  What I don't understand is why the
    > document has a
    > set of name-specific accessors for the array.  My code doesn't seem
    > to need
    > such.
    >
    <http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Co
    ncepts/AccessorConventions.html
    >

    > Furthermore, I don't understand how these accessors are getting
    > called
    > when "Add" and "Remove" buttons are clicked (yes, they trip
    > breakpoints)
    > since these are connected to the controller add/remove and I can't
    > find any
    > code or bindings that call the above named accessors.
    >
    The controller is managing the document's array.  Why wouldn't it use
    those methods?

    mmalc
  • Thank you Shawn and mmalc.  I would have never figured this out without
    that direct reference.  Even if I had read that reference previously, I
    wouldn't have made the connection and understood what was going on.

        So apparently, NSArrayController uses these methods if they are
    available -- otherwise directly accesses the array -- which my code is
    doing?  Does NSTreeController do the same?

        As far as I can tell, there is not one word about this in the
    documentation for NSArray, NSMutableArray, or NSArrayController.  There
    should be.

        I can see the value of having it.  In fact, this may be what I need to
    intercept array changes to implement item number resequencing for line
    numbering and for Core Data array retrieval.  (I don't allow resorting by
    user.  My data has a definite order.)

    > The controller is managing the document's array.  Why wouldn't it use
    > those methods?
    >
    > mmalc
    >
  • Listen, for me at least, it just isn't productive to
    jump into a large framework and attempt to implement
    fairly complex behaviors using features of the
    framework that I don't understand.

    There are lots of different learning styles.  In my
    case, I like to learn from the bottom up.  I am
    bothered when I don't know how something works at
    least conceptually.  If there is a learning style that
    prefers jumping in, using "magical" behaviors, and
    being surprised every day, I don't understand it.

    For me, using bindings and controllers without first
    understanding the much more basic accessors and data
    source concepts would be fruitless.

    > As far as I can tell, there is not one word about
    this in the
    > documentation for NSArray, NSMutableArray, or
    NSArrayController.  > There should be.

    Why should accessors and Key Value Observing be
    documented in NSArray, NSMutableArray, or
    NSArrayController ?  Nearly every class provides
    accessors.  Why are NSArray, NSMutableArray, or
    NSArrayController special ?  Is it because those are
    the classes you happen to use in your application ?
    Should the concepts of instance variables be explained
    in every reference document ?  Should Objective-C
    message dispatch be explained again in every class
    reference?

    KVC Compliance

    "The key-value coding mechanism tries hard to find a
    value for a given key, so that it is actually
    difficult not to be KVC compliant for a given
    property. Although there are a number of ways to
    ensure compliance, it is recommended that you use
    accessor methods and follow standard naming
    conventions. The general requirements for KVC
    compliance are described in Key-Value Coding Accessor
    Methods in Key-Value Coding Programming Guide."

    http://developer.apple.com/documentation/Cocoa/Conceptual/ModelObjects/Arti
    cles/moIntegrating.html


    http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Co
    ncepts/AccessorConventions.html


    http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/in
    dex.html


    http://developer.apple.com/documentation/Cocoa/Conceptual/ModelObjects/Arti
    cles/moAccessorMethods.html


    I don't mean to be harsh, and I know that learning a
    large framework can be overwhelming.  Everyone has to
    start somewhere.  However, basic concepts are already
    covered in many places, and covering them redundantly
    in every page of class documentation would ruin the
    documentation for many users.
  • Because those particular accessors appear to be specific to the
    mentioned classes.  If they are going to try to use them, their documents
    should clue you in and at least provide the reference you guys sent.  (Ok,
    the documents headers do vaguely reference the Key-Value Coding Guide, along
    with a few other encyclopedic references.)

        I follow the conventions for ivars and my own code works with bindings.
    So far I have a six level hierarchy, a detailed table view tab for each, a
    tree view for all, a browser view for all, and plan to include a 10.5
    fancy-smancy flip-through view.

    > Why should accessors and Key Value Observing be
    > documented in NSArray, NSMutableArray, or
    > NSArrayController ?  Nearly every class provides
    > accessors.  Why are NSArray, NSMutableArray, or
    > NSArrayController special ?  Is it because those are
    > the classes you happen to use in your application ?
    > Should the concepts of instance variables be explained
    > in every reference document ?  Should Objective-C
    > message dispatch be explained again in every class
    > reference?
  • On Fri, August 31, 2007 11:24 am, Gordon Apple said:
    > Because those particular accessors appear to be specific to the mentioned
    > classes.  If they are going to try to use them, their documents should
    > clue you in and at least provide the reference you guys sent.  (Ok, the
    > documents headers do vaguely reference the Key-Value Coding Guide, along
    > with a few other encyclopedic references.)

    They aren't specific to those classes.  Those classes are often a
    convinent way to store and manipulate data that will be shown using those
    accessors, but they aren't the only way by a long shot.

    NSArray (and the other NSSet sub-classes and addon classes) is simply a
    data-store class.  How you use it in your program is up to you.

    Key-Value-Coding is _one_ way of enabling simple communication between
    objects in your program.  Note that I said 'communication': it is about
    getting data from one place to another in your program, and it doesn't
    care how the data is stored or generated.  It just helps keep track of it.

    Data storage and data communication are only related because they both
    talk about data.  Often they are used together (because after or before
    communicating data you want to store it), but they don't need to be.

    Daniel T. Staal

    ---------------------------------------------------------------
    This email copyright the author.  Unless otherwise noted, you
    are expressly allowed to retransmit, quote, or otherwise use
    the contents for non-commercial purposes.  This copyright will
    expire 5 years after the author's death, or in 30 years,
    whichever is longer, unless such a period is in excess of
    local copyright law.
    ---------------------------------------------------------------
  • On Aug 31, 2007, at 8:24 AM, Gordon Apple wrote:

    > Because those particular accessors appear to be specific to the
    > mentioned classes.
    >
    No, they're not -- they're fundamental to KVC and KVO; they will work
    with any class that leverages these technologies...

    > If they are going to try to use them, their documents
    > should clue you in and at least provide the reference you guys
    > sent.  (Ok,
    > the documents headers do vaguely reference the Key-Value Coding
    > Guide, along
    > with a few other encyclopedic references.)
    >
    ... the documentation makes abundantly clear that a full understanding
    of KVC and KVO is a prerequisite for using bindings.  If you've failed
    to meet those prerequisites then a failure to understand is yours alone.

    To reiterate a point Erik made, it is not clear why some here seem to
    think that it should be possible to dive headlong into a complex
    environment and expect everything to make sense.  There are good
    pedagogical reasons why the documentation -- and some of us answering
    questions here -- stress the importance of learning the fundamentals
    first.

    mmalc
previous month august 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