Why ObjectiveResource Sucks

I could be wrong about this, so feel free to school me. Until then...

I've been screwing around with ObjectiveResource for a bit and comparing it as an option to ASIHTTP until I realized that even I can tell how bad ObjectiveResource is, so it must really suck. Why?

1. Overall architectural choice: Categories Only - these guys are Rubyists and they code like it. Ruby is an interpreted (read "slow") language which is only run in environments where it's fast enough (and with modern computers, those are many). Obj-C (especially on iPhone) ain't Ruby, so the choice to use categories instead of inheritance for your objects, while cute, costs the library dearly. Categories cannot, by definition, hold state, so you have to build the entire state every time you need something. This results in very inefficient code. As an example, put an NSLog in any of the methods of the NSObject+PropertySupport and watch 'er spin for even the simplest Web Services call. "No premature optimization" is not a get-out-of-jail pass. 
2. Overall architectural choice: Focus On Crud - I actually enjoy a good Scaffold now and again, having built major admin portions of sites that rely on  map.resources (now in Rails 3, just resources), but you'll need more than create-read-update-delete if your app is actually going to be more than a few milliseconds away from your server. Then you'd have to think about how to aggregate, and how to call other methods. There is a method called: - (BOOL)createRemoteWithParameters:(NSDictionary *)parameters andResponse:(NSError **)aError; I wonder what that does. Which leads to:
3. No Documentation At All - I mean the kind where you look at the .h and it tells you what methods actually do. But I guess if you're a Rubyist you consider all code to be self-documenting. Isn't true in Ruby, and it isn't true here. There is a five-minute walkthrough and a jumpstart.
4. No Concept of Async - While I would love to run my stuff in performInBackgroundThread, that's not really how serious business is done. Check out ASIHTTP to see how to actually do async correctly, and provide examples of it.
5. No Concept of Failure - that's right. If your Rails site is down, ObjectiveResource doesn't throw any Exceptions. In fact, it returns answers just like those you expect, only with incorrect values. It's like that employee you don't want to have, who just pretends that there are no problems while they make a small problem into a large one.

I could probably go on, but I have to finish a CRUD layer for ASIHTTP (or maybe just do some HelloWorlds and start running). I'm sure I'll be stealing lots of code from ObjectiveResource anyway.

Update: The thought of doubling my code on the client and server side was just too much to take, so I'm taking another look at ObjectiveResource. Coming back to a project after a pause often provides perspective. At least #5 is wrong. Here's the code to get it to work:

NSError *error = nil;

NSArray *posts = [Post findAllRemoteWithResponse:&error];

if (error)

NSLog(@"yes this is an error");

else {

NSLog(@"NO Error! Groovy");

}