each generally useful piece in Cocoa (NSWindow, NSButton, NSTableView, etc.) is made up of smaller, but equally useful pieces (NSView, NSControl, etc.) It's more finely grained than Rails.
Having actually gone down the road of porting a framework from the desktop space to the web, I think it's a mistake to assume that you're solving the same sorts of problems and need the same kind of design. Having a browser wedged between the app and the user changes everything.
In Rails, the "top-level" abstractions like ActiveRecord are pretty much opaque (in that they aren't made of smaller, but also useful pieces).
Cocoa's counterpart to ActiveRecord is NSManagedObject. You really can't break a managed object down into separate parts but this doesn't prevent Core Data from being effective at what it sets out to do.
Rails is self-admittedly "opinionated software" that dictates (or at least "suggests very, very strongly") how you shall go about building a Rails app. Cocoa, on the other hand, is more in the tradition of general-purpose APIs
I don't think I could disagree more, especially when Core Data is factored in. You can certainly choose not to use the standard design patterns, Xcode's models or NIB files, but you'd be making just as much work for yourself as if you chose to go against the grain in Rails.
Maybe if you had some specific examples I'd get a better idea of what you're getting at.
by Scott Stevenson — Feb 28
Having actually gone down the road of porting a framework from the desktop space to the web, I think it's a mistake to assume that you're solving the same sorts of problems and need the same kind of design. Having a browser wedged between the app and the user changes everything.
In Rails, the "top-level" abstractions like ActiveRecord are pretty much opaque (in that they aren't made of smaller, but also useful pieces).
Cocoa's counterpart to ActiveRecord is NSManagedObject. You really can't break a managed object down into separate parts but this doesn't prevent Core Data from being effective at what it sets out to do.
Rails is self-admittedly "opinionated software" that dictates (or at least "suggests very, very strongly") how you shall go about building a Rails app. Cocoa, on the other hand, is more in the tradition of general-purpose APIs
I don't think I could disagree more, especially when Core Data is factored in. You can certainly choose not to use the standard design patterns, Xcode's models or NIB files, but you'd be making just as much work for yourself as if you chose to go against the grain in Rails.
Maybe if you had some specific examples I'd get a better idea of what you're getting at.