Return an empty container from select, reject, etc...

[mbrandonw]

It seems that a more consistent API choice for the select/reject family of methods is to return an empty container (NSSet, NSArray or NSDictionary) instead of nil when nothing is matched.

Maybe it's too late to change this, but conceptually I think it makes more sense.

[zwaldowski]

I suppose it would be closer to the API, but BlocksKit isn't just about
wrapping the collection block API's. If it was, then I'd just recommend
using autocomplete and calling it a day. The match/reject family intends to
make code more expressive and declarative. Returning nil allows someone to
just check 'if (!results)' instead of accessing the count property et. al.
You shouldn't be keeping an empty collection around any longer than
absolutely necessary. If you're not getting any results from match/reject
then you should be skipping the code that would be using those results;
conceptually, we're not giving back a set of results that is empty, we're
giving back no results. I do see your point, but I see no practical reason
to break our API.

Thanks for using and contributing to BlocksKit!

[zwaldowski]

I recently heard some rather convincing arguments as per this issue. I think we might change it for the next release.

[mbrandonw]

Cool, I still stand behind this change.

Brandon Williams

On Saturday, February 18, 2012 at 5:25 PM, Zachary Waldowski wrote:

I recently heard some rather convincing arguments as per this issue. I think we might change it for the next release.

---

Reply to this email directly or view it on GitHub:
#34 (comment)

[zwaldowski]

Completed in BlocksKit 1.0.6.