On 17 Apr '08, at 9:56 PM, Adam P Jenkins wrote:
Can you give an example of where invoking methods on nil objects
would make sense in a non-error-path situation? I'm not trying to
be argumentative here, I'm really curious to know what Objective-C
idioms take advantage of the
On 18 Apr 2008, at 07:18, [EMAIL PROTECTED] wrote:
Date: Fri, 18 Apr 2008 00:56:13 -0400
On Apr 18, 2008, at 12:47 AM, Bill Bumgarner wrote:
On Apr 17, 2008, at 11:20 PM, Adam P Jenkins wrote:
Exactly. And now that the convention of methods returning self no
longer exists, it seems like
On 18 Apr 2008, at 06:20, Adam P Jenkins wrote:
Of course (and as you have discovered), there are an awful lot of
situations where a 'nil' return value is actually indicative of a
serious problem -- something has failed that shouldn't have. And
tracking it down can be a pain.
Exactly.
On 18 Apr 2008, at 05:56, Adam P Jenkins wrote:
On Apr 18, 2008, at 12:47 AM, Bill Bumgarner wrote:
On Apr 17, 2008, at 11:20 PM, Adam P Jenkins wrote:
Exactly. And now that the convention of methods returning self no
longer exists, it seems like there's no longer any advantage to
this
On Apr 18, 2008, at 1:16 AM, Graham Cox wrote:
Here's a simple example:
- (void) dealloc
{
[someIvar release];
[super dealloc];
}
is someIvar really initialised? Maybe it's nil? Do I care at this
point? no - either way, the code is correct - if the object was
made, it's released,
Here's a simple example:
- (void) dealloc
{
[someIvar release];
[super dealloc];
}
It's worth noting that even in C++ there's a special case for delete, so
that one can write delete myptr rather than if(myptr) delete myptr) 10
bazillion[1] times. I was around when this behavior was
On Apr 18, 2008, at 9:56 AM, Adam P Jenkins wrote:
On Apr 18, 2008, at 1:16 AM, Graham Cox wrote:
Here's a simple example:
- (void) dealloc
{
[someIvar release];
[super dealloc];
}
is someIvar really initialised? Maybe it's nil? Do I care at this
point? no - either way, the code is
I'm curious if anyone knows the rationale behind the decision to make
sending messages to nil be a no-op in ObjC. I've used a number of
other OO languages, including C++, Java, Python, Ruby, Smalltalk, and
Javascript, and in all of them, trying to invoke a method on whatever
their
On Apr 17, 2008, at 5:42 PM, Adam P Jenkins wrote:
I'm curious if anyone knows the rationale behind the decision to
make sending messages to nil be a no-op in ObjC. I've used a
number of other OO languages, including C++, Java, Python, Ruby,
Smalltalk, and Javascript, and in all of them,
I find it very useful, since messages to nil are valid, a whole lot of
exception handling can be avoided (since it's done for you). Generating a
run-time error would imply that you shouldn't send a message to nil, which
would mean that you ought to do nil checks each time you change/set a
pointer.
On 18 Apr 2008, at 8:42 am, Adam P Jenkins wrote:
trying to invoke a method on whatever their equivalent of nil is
produces a runtime error of some sort.
Actually in C++ it produces a solid, good old fashioned crash (I don't
know about the others).
This isn't good - it means you have to
On Thu, Apr 17, 2008 at 9:19 PM, Graham Cox [EMAIL PROTECTED] wrote:
Actually in C++ it produces a solid, good old fashioned crash (I don't know
about the others).
This isn't good - it means you have to check every single return value and
pointer for nil before you can use it - code ends
On Apr 17, 2008, at 7:07 PM, Bill Bumgarner wrote:
(1) And many Java programmers find the constant need to check for
nulls or null pointer exceptions to be ugly and inconvenient
I would agree that this was a problem if I thought it was common to
encounter situations where invoking
On Apr 17, 2008, at 11:20 PM, Adam P Jenkins wrote:
Exactly. And now that the convention of methods returning self no
longer exists, it seems like there's no longer any advantage to this
behavior.
There are 10s of thousands invocations of methods on nil objects
during the normal,
On Apr 18, 2008, at 12:47 AM, Bill Bumgarner wrote:
On Apr 17, 2008, at 11:20 PM, Adam P Jenkins wrote:
Exactly. And now that the convention of methods returning self no
longer exists, it seems like there's no longer any advantage to
this behavior.
There are 10s of thousands invocations
On Apr 17, 2008, at 9:19 PM, Graham Cox wrote:
On 18 Apr 2008, at 8:42 am, Adam P Jenkins wrote:
trying to invoke a method on whatever their equivalent of nil is
produces a runtime error of some sort.
Actually in C++ it produces a solid, good old fashioned crash (I
don't know about the
On 18 Apr 2008, at 3:01 pm, Adam P Jenkins wrote:
I don't understand how the nil-swallows-messages behavior relieves
you of having to check for errors.
I never said it did. But there are plenty situations where getting nil
isn't an error, it's just reflective of a particular state.
The
A common place I see nil swallowing is pulling arrays from a
dictionary or hash table.
NSArray * theArray = get_next(table);
int i, count = [theArray count];
for(i = 0;i count;i++)
{
//do stuff
}
If the array is nil count is zero and the for loop is not entered.
Avoided adding
On Fri, Apr 18, 2008 at 12:56 AM, Adam P Jenkins [EMAIL PROTECTED]
wrote:
Can you give an example of where invoking methods on nil objects would
make sense in a non-error-path situation? I'm not trying to be
argumentative here, I'm really curious to know what Objective-C idioms take
19 matches
Mail list logo
