EXC_BAD_ACCESS when using function style API calls on a nil receiver about enumeratorkit

[alaroldai]

I’m not sure that forcing the user to make sure the receiver is non-nil violates any Objective-C conventions - in fact, I’d say that it actually enforces the conventions. Every Objective-C method that takes an object argument either implicitly assumes that the argument is non-nil and relies on the “sending messages to nil returns nil” language feature, or checks the value of the argument before using it. That pattern seems very similar to what you’ve got here.

And although the function-style enumeration is cool, it doesn’t really match Objective-C style - block properties are fairly rare, and using the dot syntax to invoke a callable is pretty much the opposite direction to where Objective-C diverged from C: It’s closer to the C++ (and Java) family of OO languages than the Smalltalk family.

Also, if you expand “each” to “for each, do” it’s a verb phrase, so it makes more sense that each would be a method rather than a property. Properties don’t really imply action in the same way methods do, and I can’t think of a reason somebody would call “each” without intending to enumerate over the collection.

Reading the code could be easier using the message-send notation as well - using the function-style block invocation I’d need to know the EnumeratorKit API to understand what the type of “each” is and what it’s for, whereas using the standard objective-c method syntax would make it clearer that an action is being performed, rather than a property being accessed. It also makes it clear to the reader that the functionality of “each” is under EnumeratorKit’s control instead of having to check the definition to make sure its’ read-only.

In the end, I think the only way you’d be able to get the desired effect would be to define “each” as a very complicated macro (which would be incredibly bad coding style and could lead to some hard-to-trace bugs). There’s no way to intercept the “each” message as the runtime won’t even get to the stage of figuring out what class the receiver belongs to (the isa pointer will be nil, even if objc_messageSend doesn’t check for a nil target), and having “each” return a subclass of NSBlock with a different implementation of “invoke” won’t help for the same reason.

It’s really a choice between the familiar Ruby/Java/C++ dot-notation method invocation syntax, and the Objective-C style method invocation. I’ll admit, I’m a little biased toward the latter because the colon character reminds me of python’s loop syntax and the square brackets look a bit like a list comprehension.

That said, I do like the function-style invocations - they’re extremely concise and Ruby-esque - so I’ll have a closer look at this in the morning.

Alastair Daivis
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)

On Tuesday, 16 July 2013 at 18:54 , Adam Sharp wrote:

This kind of code works just as expected:
@[@1, @2, @3].each(^(id num){ NSLog(@"%@", num); });

However, there is a hidden bug in this method:

• (void)doStuffWithArray:(NSArray *)array { array.each(^(id obj){ NSLog(@"%@", obj); }); }

The problems is that sending -each to a nil array returns nil, and then the method tries to invoke the result as a block, causing the EXC_BAD_ACCESS. This, however, works as expected:

• (void)doStuffWithArray:(NSArray *)array { [array each:^(id obj){ // if array is nil, this block will never be called -- yay! NSLog(@"%@", obj); }]; }

By convention, most Objective-C developers would probably expect this method to fail gracefully if array was nil, but without an explicit guard it's not possible:

• (void)doStuffWithArray:(NSArray *)array { if (array) { // yuck! array.each(^(id obj){ NSLog(@"%@", obj); }); } }

According to Objective-C conventions, this kind of violates the principle of least surprise, putting the responsibility onto users to add guards such as this in their code. Requiring additional boilerplate like this kind of negates any syntactic sugar benefits you get from the API at this point.
It would be really nice if there was a more object-oriented / dynamic way of invoking blocks, like Ruby's yield or block.call. (Alas, -[block invoke] is private API. Not that it would help in this case.)
Any ideas? I feel like I may need to deprecate the function-style API calls... :(
/cc @alaroldai (https://github.com/alaroldai)

—
Reply to this email directly or view it on GitHub (#4).

[sharplet]

@alaroldai All good points. At this point, my plan is to deprecate the block property API in v0.2 and remove it in a subsequent release.

[sharplet]

Actually, leaving this open at least until I add the deprecation.