autorelease method
-
Hi
Why is does that not throw a warning and even works?
NSArray* myArray = [[[NSArray alloc] init] autorelease];
Denis
PS: its only an example, I know I can use [NSArray array]; -
Why should it throw an exception? It just creates an empty NSArray
instance, autoreleased.
It's not good for much, though. Perhaps you want to use
NSMutableArray instead?
Roland
On Oct 13, 2005, at 5:04 PM, Denis Ahrens wrote:> Hi
>
> Why is does that not throw a warning and even works?
>
> NSArray* myArray = [[[NSArray alloc] init] autorelease];
>
> Denis
>
> PS: its only an example, I know I can use [NSArray array];
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
> -
On Oct 13, 2005, at 6:04 PM, Denis Ahrens wrote:> Hi
>
> Why is does that not throw a warning and even works?
>
> NSArray* myArray = [[[NSArray alloc] init] autorelease];
Because there is nothing wrong with it, other than semantically that
you have a non-mutable empty array, which is probably not that useful
in most cases?
Chad>
> Denis
>
> PS: its only an example, I know I can use [NSArray array];
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On 14/10/2005, at 2:21 PM, Chad Leigh wrote:>> Why is does that not throw a warning and even works?
>> NSArray* myArray = [[[NSArray alloc] init] autorelease];
>>
>
> Because there is nothing wrong with it, other than semantically
> that you have a non-mutable empty array, which is probably not that
> useful in most cases?
Except where Cocoa/Carbon require an empty array (rather than nil),
for whatever obscure reason. NSScriptObjectSpecifiers and Keychain
Services are a couple of examples, but I seem to recall there are
others.
Dunno why it was designed that way. I would certainly prefer to just
pass nil/NULL, rather than having to instantiate and autorelease a
new object.
Cheers,
Tobias Peciva
Pharos Systems -
Am 14.10.2005 um 04:01 schrieb Tobias Peciva:> On 14/10/2005, at 2:21 PM, Chad Leigh wrote:
>
>
>>> Why is does that not throw a warning and even works?
>>> NSArray* myArray = [[[NSArray alloc] init] autorelease];
>>>
>>>
>>
>> Because there is nothing wrong with it, other than semantically
>> that you have a non-mutable empty array, which is probably not
>> that useful in most cases?
>>
>
> Except where Cocoa/Carbon require an empty array (rather than nil),
> for whatever obscure reason.
Empty arrays are useful as return values because you can copy them
blindly. Imagine -[Foo someArray] either returning nil or [NSArray
array], when the result is empty.
array = [[foo someArray] mutableCopy];
bar = [Bar new];
[array addObject:bar];
[bar release]; // bar would be gone, if foo returned nil
[foo setSomeArray:array];
[array release];
If nil is a possiblity the code would have to be
array = (id) [foo someArray];
array = array ? [array mutableCopy] : [NSMutableArray new];
bar = [Bar new];
[array addObject:bar];
[bar release];
[foo setSomeArray:array];
[array release];
So it depends on the circumstances, but as a personal preference I
usually try to return empty arrays instead of nil.
Ciao
Nat!
------------------------------------------------------
See I reckon you're about an eight or a nine,
Maybe even nine and a half
in four beers time. -- The Streets -
On Oct 14, 2005, at 2:19 PM, Nat! wrote:> Empty arrays are useful as return values because you can copy them
> blindly.
This takes the cake (in my book) for most worthless object usage. It
also adds a hefty dose of obfuscation to whatever you're trying to
accomplish, not to mention that it screws up maintainability of the
code for the next guy who comes across it.
Roland -
The best reason for a method to return an empty array is *because it
is the correct value*.
Consider a NSView with no subviews. What should subviews return?
nil means one thing, an empty array means something else, and [NSNull
null] means something else entirely.
Copying an immutable object is often equivalent to a retain, so no
new objects are created. Not that I have the Foundation source, but
an empty immutable array certainly sounds like a good candidate for
this kind of optimization.
Keep in mind that the above example could quite possible return
[[mutableArray copy] autorelease], which probably sounds like the
most worthless object usage as well, but it's also correct.
(Here's dreading the day when NO_NIL_RECEIVERS becomes defacto
practice ;)
--dave
On Oct 14, 2005, at 2:33 PM, Roland Torres wrote:>
> On Oct 14, 2005, at 2:19 PM, Nat! wrote:
>
>
>> Empty arrays are useful as return values because you can copy them
>> blindly.
>>
>
> This takes the cake (in my book) for most worthless object usage.
> It also adds a hefty dose of obfuscation to whatever you're trying
> to accomplish, not to mention that it screws up maintainability of
> the code for the next guy who comes across it.
>
> Roland
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On 14. Okt 2005, at 23:53 Uhr, David Young wrote:> nil means one thing, an empty array means something else, and
> [NSNull null] means something else entirely.
Could you summarize why NSNull is something entirely different than
nil from a semantical point of view?
Thanks a lot,
Helge -
I'm not sure how semantically , but [NSNull null] is a null that's
not zero. So
if ([anObject something]) {
/* something returned nil -- does not execute */
}
if ([anObject something]) {
/* something returned NSNull -- executes */
}
You could say that NSNull is a hack, and that NSNull and nil mean the
same thing, but the above is a case where they don't.
--dave
On Oct 15, 2005, at 7:21 PM, Helge Hess wrote:> On 14. Okt 2005, at 23:53 Uhr, David Young wrote:
>
>> nil means one thing, an empty array means something else, and
>> [NSNull null] means something else entirely.
>>
>
> Could you summarize why NSNull is something entirely different than
> nil from a semantical point of view?
>
> Thanks a lot,
> Helge
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On Oct 16, 2005, at 3:10 PM, David Young wrote:> You could say that NSNull is a hack, and that NSNull and nil mean
> the same thing, but the above is a case where they don't.
NSNull can also be stored in collection classes like NSArray.
Charlton
--
Charlton Wilbur
<cwilbur...>
<cwilbur...> -
They're different semantically because nil is an error to get out of
or put in a collection (e.g. NSArray) and NSNull is not. It's there
for the same reason we have NSNumber.
-bob
On Oct 16, 2005, at 12:10 PM, David Young wrote:> I'm not sure how semantically , but [NSNull null] is a null that's
> not zero. So
>
> if ([anObject something]) {
> /* something returned nil -- does not execute */
> }
>
> if ([anObject something]) {
> /* something returned NSNull -- executes */
> }
>
> You could say that NSNull is a hack, and that NSNull and nil mean
> the same thing, but the above is a case where they don't.
>
> --dave
>
> On Oct 15, 2005, at 7:21 PM, Helge Hess wrote:
>
>
>> On 14. Okt 2005, at 23:53 Uhr, David Young wrote:
>>
>>
>>> nil means one thing, an empty array means something else, and
>>> [NSNull null] means something else entirely.
>>>
>>>
>>
>> Could you summarize why NSNull is something entirely different
>> than nil from a semantical point of view?
>>
>> Thanks a lot,
>> Helge
>>
>> _______________________________________________
>> MacOSX-dev mailing list
>> <MacOSX-dev...>
>> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>>
>>
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
> -
On 16. Okt 2005, at 21:24 Uhr, Charlton Wilbur wrote:> On Oct 16, 2005, at 3:10 PM, David Young wrote:
>> You could say that NSNull is a hack, and that NSNull and nil mean
>> the same thing, but the above is a case where they don't.
> NSNull can also be stored in collection classes like NSArray.
Yes, those are technical differences and I'm aware of them. But from
a conceptual point of view, they are the same, no?
I'm interested whether people use NSNull in different ways but as an
object representation of nil (to allow it being added to collections
or in KVC).
E.g do you actually return 'nil' for errors in your methods and
'NSNull' for empty values (in _real world_ code)?
Basically the same question like: do you use NSNumber's for anything
but the mentioned contexts? (KVC and wrapping of base types)
Thanks,
Helge -
(Probably already answered since I get the digest, but ...)
On Oct 16, 2005, at 3:00 PM, Helge Hess wrote:>> nil means one thing, an empty array means something else, and
>> [NSNull null] means something else entirely.
>
> Could you summarize why NSNull is something entirely different than
> nil from a semantical point of view?
nil is a zero pointer, essentially (and as an implementation detail)
equivalent to NULL or (void*)0. [NSNull null] is an actual object
meant to act as the placeholder. It's the equivalent of a book page
imprinted with "This page intentionally left blank." -
I think of NSNull does only a passable job of being a nil for
collections. The awkwardness in this usage is that you have to
explicitly test to see if a returned object is NSNull when iterating
through your collections. It also doesn't behave like nil in that
messages to NSNull actually go somewhere, and they will raise an
exception of NSNull doesn't implement them, so using NSNull precludes
makeObjectsPerformSelector:. If NSNull really were just nil for
containers, it should probably ignore messages it doesn't implement.
Still, I have used NSNull in collections where the collection is a
list of "operands for some operation", e.g., a list of HTTP proxy
servers NSURLs. Finding the NSNull meant not using a proxy server and
going directly to the destination. It's good for stuff like that.
There's a new object in the 10.3.9+ WebKit, JSUndefined, that reminds
me a lot of NSNull. It seems to be used to represent not anything and
not null, though I admit to not having used it. The concept of the
object that means something unique (and which can only be defined as
itself) is interesting, but the only analogue I can think of off of
the top of my head would be something like a NSInfiniteNumber.
I don't think I would ever return NSNull from a method to indicate
anything, no. The problem with NSNull as an empty value is that it
isn't, because it is the only instance of a type which has no value
to be empty! An object which possesses a value, like NSArray, can
also possess the emptiness of the array, and so that's more correct
in the case of "returning something that's empty". So we're back at +
[NSArray array] being useful. :)
--dave
On Oct 16, 2005, at 12:47 PM, Helge Hess wrote:> On 16. Okt 2005, at 21:24 Uhr, Charlton Wilbur wrote:
>
>> On Oct 16, 2005, at 3:10 PM, David Young wrote:
>>
>>> You could say that NSNull is a hack, and that NSNull and nil mean
>>> the same thing, but the above is a case where they don't.
>>>
>> NSNull can also be stored in collection classes like NSArray.
>>
>
> Yes, those are technical differences and I'm aware of them. But
> from a conceptual point of view, they are the same, no?
>
> I'm interested whether people use NSNull in different ways but as
> an object representation of nil (to allow it being added to
> collections or in KVC).
> E.g do you actually return 'nil' for errors in your methods and
> 'NSNull' for empty values (in _real world_ code)?
>
> Basically the same question like: do you use NSNumber's for
> anything but the mentioned contexts? (KVC and wrapping of base types)
>
> Thanks,
> Helge
>
> _______________________________________________
> MacOSX-dev mailing list
> <MacOSX-dev...>
> http://www.omnigroup.com/mailman/listinfo/macosx-dev
>
