Returning nil or empty array?

  • What is nicer?

    Returing an empty array or nil?

    I have a method that return a set of elements and I want to know what
    is the best thing to do when there is 0 element to return.

    Regards.
  • > What is nicer?
    >
    > Returing an empty array or nil?
    >
    > I have a method that return a set of elements and I want to know what
    > is the best thing to do when there is 0 element to return.

            I've thought about this before and I've settled on returning an empty array. I think it better models what is intended. You can also enumerate the elements in an empty array without having to check whether the array exists or not.
  • >> What is nicer?
    >>
    >> Returing an empty array or nil?
    >>
    >> I have a method that return a set of elements and I want to know what
    >> is the best thing to do when there is 0 element to return.
    >
    > I've thought about this before and I've settled on returning
    > an empty array. I think it better models what is intended. You can
    > also enumerate the elements in an empty array without having to
    > check whether the array exists or not.

    This is what I was thinking too. Now I would like to know when I
    should use NSArray or NSMutableArry. I think that I am using NSArray
    too much. I'm using a lot of mutable array in my methods but I am
    always return non mutable by coping the content of the mutable array
    to the one that is not. It is good practice to return NSArray objects
    or returning NSMutalbeArray is ok too?

    I don't remember why I am doing this...

    Regards.

    Tib.
  • You can also simply return your NSMutableArray as an NSArray.

    - (NSArray*)someMethod
    {
        NSMutableArray *array = [NSMutableArray arrayWithCapacity:100];
        [array addObject:.....];
        .....

        return array;
    }

    the caller doesn't have to know it is a Mutable array.

    ----------------------------------
    Henri Lamiraux
    Engineering Manager
    User Interface Tools Group
    Apple
    <lamiraux...>

    > From: Pierre Thibault <p.thibault...>
    > Date: Tue, 19 Dec 2000 18:41:36 -0500
    > To: <macosx-dev...>
    > Subject: Re: Returning nil or empty array?
    >
    > This is what I was thinking too. Now I would like to know when I
    > should use NSArray or NSMutableArry. I think that I am using NSArray
    > too much. I'm using a lot of mutable array in my methods but I am
    > always return non mutable by coping the content of the mutable array
    > to the one that is not. It is good practice to return NSArray objects
    > or returning NSMutalbeArray is ok too?
    >
    > I don't remember why I am doing this...
    >
    > Regards.
    >
    > Tib.
  • > Now I would like to know when I should use NSArray or NSMutableArry.
    > I think that I am using NSArray too much. I'm using a lot of mutable
    > array in my methods but I am always return non mutable by coping the
    > content of the mutable array to the one that is not. It is good
    > practice to return NSArray objects or returning NSMutalbeArray is ok
    > too?

    It doesn't matter. All NSArrays in Public Beta are mutable ones.

    andy
  • Yes it matters. If you want to tell the caller that the array you are
    returning should not be modified you better return a NSArray. Yes it is true
    that the caller can always typecast it to a NSMutableArray and add/remove
    objects but in this case you are not reponsible for the outcome.

    ----------------------------------
    Henri Lamiraux
    Engineering Manager
    User Interface Tools Group
    Apple
    <lamiraux...>

    > From: Andreas Monitzer <a...>
    > Date: Wed, 20 Dec 2000 08:07:35 +0100
    > To: <macosx-dev...>
    > Subject: Re: Returning nil or empty array?
    >
    >> Now I would like to know when I should use NSArray or NSMutableArry.
    >> I think that I am using NSArray too much. I'm using a lot of mutable
    >> array in my methods but I am always return non mutable by coping the
    >> content of the mutable array to the one that is not. It is good
    >> practice to return NSArray objects or returning NSMutalbeArray is ok
    >> too?
    >
    > It doesn't matter. All NSArrays in Public Beta are mutable ones.
    >
    > andy
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
    >
  • On Wednesday, December 20, 2000, at 06:45 PM, Henri Lamiraux wrote:

    > Yes it matters. If you want to tell the caller that the array you are
    > returning should not be modified you better return a NSArray. Yes it is true
    > that the caller can always typecast it to a NSMutableArray and add/remove
    > objects but in this case you are not reponsible for the outcome.

    But it's not necessary to copy an NSMutableArray to an NSArray. If your official return type is NSArray or NSMutableArray does matter of course.

    andy

    --
    Description forthcoming.
  • Yes, it is not necessary.

    ----------------------------------
    Henri Lamiraux
    Engineering Manager
    User Interface Tools Group
    Apple
    <lamiraux...>

    > From: Andreas Monitzer <a...>
    > Reply-To: <a...>
    > Date: Wed, 20 Dec 2000 19:09:11 +0100
    > To: <macosx-dev...>
    > Subject: Re: Returning nil or empty array?
    >
    > But it's not necessary to copy an NSMutableArray to an NSArray.
  • Now it is what I'm doing:

    I return an NSMutableArray if possible. It is more fun for the caller
    to have a mutable array. Otherwise, it is an NSArray.

    I return an empty array when they are no elements but I return nil to
    mean there is no value at all.

    I think this is the best way to deal with that.

    Regards.
  • On Wednesday, December 20, 2000, at 06:15 PM, Henri Lamiraux wrote:

    > Yes, it is not necessary.

    Though it's good practice ... other programmers may write code that
    depends on you returning a mutable array, so even though their doing
    that is bad practice, it makes sense to allow for it.
  • > I've thought about this before and I've settled on returning an empty
    array. I think it better models what is intended.
    > You can also enumerate the elements in an empty array without having
    to check whether the array exists or not.

    This is consistent with Cocoa APIs, which treat "nil" not as a valid
    array (or string, or whatever), but as an exceptional case. For
    instance, most methods that take NSStrings or NSArrays do not accept
    nil, unless otherwise documented. Similarly for return values.

    Having your methods return empty arrays or strings to indicate no value
    makes it easier to hook the various APIs together, "lego" style.

    As far as the mutable array vs array distinction, just to reiterate: If
    the method declaration says (NSArray *), the caller is not supposed to
    modify it, whether or not a mutable array is returned.  So mutable array
    return is usually fine. Cases where it might not be fine is if you
    return a mutable array that is still changing, so the value the caller
    got changes from under them.

    Ali

    Begin forwarded message:

    > From: Eric Marshall <eric...>
    > Date: Tue Dec 19, 2000  12:17:44 PM US/Pacific
    > To: <macosx-dev...>
    > Subject: Re: Returning nil or empty array?
    >
    >> What is nicer?
    >>
    >> Returing an empty array or nil?
    >>
    >> I have a method that return a set of elements and I want to know what
    >> is the best thing to do when there is 0 element to return.
    >
    > I've thought about this before and I've settled on returning an empty
    > array. I think it better models what is intended. You can also
    > enumerate the elements in an empty array without having to check
    > whether the array exists or not.
    > _______________________________________________
    > MacOSX-dev mailing list
    > <MacOSX-dev...>
    > http://www.omnigroup.com/mailman/listinfo/macosx-dev
  • > From: Andreas Monitzer <a...>
    > Reply-To: <a...>
    > Date: Wed, 20 Dec 2000 19:09:11 +0100
    > To: <macosx-dev...>
    > Subject: Re: Returning nil or empty array?
    >
    > But it's not necessary to copy an NSMutableArray to an NSArray.

    That depends on whether or not you're returning an array created within the method, or a static array.

    For example consider the following code:

    - (NSArray*)someObjects
    {
    NSMutableArray* array = [NSMutableArray array];
    {
      // Fill in contents of array here.
      ...
    }
    return array;
    }

    In this example, the array would only exist in mutable form within the scope of the method.  Since we return it as a NSArray, without further casting, the contents of the array should never change.  Although if the array contains mutable objects, those could still change.

    If you had a class with a global NSMutableArray, and wanted to return the array to the user, but wanted to preserve the privateness of the structure.  I.e. you don't want them to manipulate the array directly, only see it's contents.  You could either return the NSMutable array as a NSArray or return a copy of it.  Returning just a NSArray pointer would be faster, for quick temporary references to the contents.  But beware, if the array is retained, it's contents could change before it's used.  Run the following and compare the contents of the strings and array as you step though it.

    /* 01 */    NSMutableString* mString = [NSMutableString stringWithString:@"test"];
    /* 02 */    NSString* aString = [NSString stringWithString:mString];
    /* 03 */    NSString* bString = [NSString stringWithString:aString];
    /* 04 */    NSString* cString = mString;
    /* 05 */    NSString* dString = nil;
    /* 06 */     [mString appendString:@"ing"];
    /* 07 */    dString = mString;
    /* 08 */    if (dString)
      {
    /* 09 */         NSMutableArray* mArray = [NSMutableArray arrayWithObjects:mString, aString, bString, cString, nil];
    /* 10 */         NSArray*    aArray = [NSArray arrayWithArray:mArray];
    /* 11 */        NSArray*    bArray = [NSArray arrayWithArray:aArray];
    /* 12 */        NSArray*    cArray = mArray;
    /* 13 */        NSArray*    dArray = nil;
    /* 14 */        [mArray addObject:dString];
    /* 15 */        dArray = mArray;
    /* 16 */        if (dArray)
      {
      }
      }

    I think there is a missing memory optimization in Cocoa.  If I create a non-mutable string, that string will forever be non-mutable.  So why when calling [NSString stringWithString:aString] in the same NSZone, do I get a separate NSString.  It seems to me, that if the passed in string is non-mutable you could simply return it.

    In my assignment methods, I usually create a non-mutable string incase the passed value was mutable.  But if the passed in string was non-mutable, it will be forever non-mutable, why duplicate it.  I suppose I could litter my code with optional checks, but wouldn't it be nice to simple say:

    - (void)setName:(in NSString*)inName
    {
    [name autorelease];
    name = [[NSString stringWithString:inName] retain];
    }

    Why not let the stringWithString: message understand that it would be redundant to copy the non-mutable string.

    Keep in mind that NSString/NSMutableString, NSArray/NSMutableArray, NSDictionary/NSMutableDictionary all have the mutable form inheriting from the non-Mutable form.  So if you have to build a mutable string or dictionary within the scop of you method, for the sole purpose of building the return value, you can safely return them as non-mutable without converting them.

    As far as returning nil or an empty array, unless you want to document it in your API, that a particular function could return nil, follow the API and return an NSAarray*.  I have to admit, though, that I have places where I return nil for an NSArray.  I do in places, where an instance doesn't have an attached array.  Again though, it comes down do the API and how you document it.

    By now, you know why I don't write user manuals.  But I hope this helps.

    Brant
previous month december 2000 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