Page 363, Kochan 2.0 -- questions about sorting of arrays

Discussion in 'Mac Programming' started by mdeh, Feb 4, 2009.

  1. mdeh macrumors 6502

    Jan 3, 2009
    Hi all,

    Program 15:13 gives an example of sorting an array, using the "sortUsingSelector" method. Because the array contains, as it's elements, AddressCards, ( which in turn contain 2 NSStrings), the "selector" chosen ( defined below) compares two NSStrings.
    Some questions have arisen, which I would like to pose to the group.

    Question 1: (Somewhat Indirectly associated with p 363).
    (Collections Programming Topics for Cocoa, Apple documentation).
    This is clearly ( well, I hope clearly) different from a **sorted** array, but how. Does "ordered" refer to the sequential allocation of elements?

    Question 2: About the middle of the page:

    If one compares this to a description of the term Comparator in "sortUsingSelector"
    then I wonder if I am being nitpicky, or whether I am missing something here. In other words, the more generic description allows the compiler (??) to choose a quicksort/bubblesort etc, ie it does not decide **how** to sort, it simply says **sort these two things**

    Last Question ( all these damned question!!!! :) )

    The defintion for the compare method is thus.
    -(NSComparisonResult) compareNames: (id) element
    return [ name compare: [element name] ]
    Why is "element" declared as type (id)?. Is this a requirement of the compare method of NSString? The name "element" is unique, or just an identifier chosen by the programmer.

    thanks as usual
  2. eddietr macrumors 6502a

    Oct 29, 2006
    So it means that the array is in an order. It doesn't mean the order is meaningful or "sorted" in any particular way.

    It just means there is a first element, a second element, and so on. And therefore it is possible to refer to the nth element of the array.

    Right, you are not defining the algorithm that NSArray will use in the sort. But it uses a comparison based algorithm meaning that as it goes through the array it needs to answer the question does this element "a" belong before or after this element "b". To answer that question it sends a message to "a" that looks sort of like this:

    [a comparator:b]
    Where b is the id of the element "b". So it is asking "a": "Do you belong before or after this other element b?"

    Then the NSArray sort implementation will call that comparator as many times as needed to check that the every element is in the correct order.

    It is of type (id) because the NSArray sort implementation doesn't know and doesn't care really about the classes of objects in the Array. All it needs to do is ask each object how it compares to some other object. So it just passes an NSObject id to the comparator.

    And yes, it's like any other method definition, you can name the parameter anything you want. That identifier "element" exists just within that scope.

    Hope that helps?
  3. mdeh thread starter macrumors 6502

    Jan 3, 2009
    Ok...that makes perfect sense.

    Yes..that's what I figured. I was confused by the term "first" in Steve's description, as I thought that part was "black box" implementation.

    Just to play devil's advocate, if I ( the programmer) **know** that the object is, say, an "AddressCard* " , would it be regarded as Poor programming to use that instead of type ID, or is it more than that.

    For example:
    -(NSComparisonResult) compareNames: (AddressCard * ) element
    	return [ [element name] compare: name ];
    Thanks in advance for that illuminating response.
    As always, appreciated.
  4. eddietr macrumors 6502a

    Oct 29, 2006
    Well, remember the code that is calling compareNames: doesn't know the type, though. (Because NSArrays can store any objects, and they don't have to even be of the same class).

    In Java for example, you could say something like:

    Collections.sort (someCollection, new Comparator<AddressCard> () {...});

    and then the compare method in that Comparator would be something like:

    int compare (AddressCard a1, AddressCard a2) {...}

    That is using Java's generics feature, and it assumes that your collection is of type Collection<AddressCard>.

    But Cocoa/ObjC doesn't have that feature, so all the sort code can do is assume that the objects being sorted are NSObjects. So all it can do is pass you an id.

    Within your comparison, though, you can test that the object being passed to you is of a particular type, or responds to a certain selector(s) or whatever you need to make the comparison.
  5. mdeh thread starter macrumors 6502

    Jan 3, 2009
  6. skochan macrumors regular

    Apr 1, 2006
    I'm really impressed by all the participation in this forum and all the help everyone is willing to offer. You've all been doing such a great job with your careful explanations (Michael - mdeh - I'm sure will agree).

    I've enjoyed standing back and letting someone else explain a concept because it is often more illuminating than having it explained the same way twice (it's not because I'm lazy -- really :))


    Steve Kochan

Share This Page