3 ms·
> That means, no writing everything twice (header files, > type declarations) Your header files can be practically empty if you don't need to show somethin
by rimantas 14y ago
> That means, no writing everything twice (header files,
> type declarations)
Your header files can be practically empty if you don't need to show something to outside. Just put your @property'ies into class extension. Even @synthesize no longer needed (most of the time, there are exceptions).
> Working with collections like arrays and hashes is MUCH
> more convenient. You can spend a good part of your time
> doing just that.
With latest versions of XCode it is possible to use foo[5] instead of [foo objectAtIndex:5] and foo[@"bar"] instead of [foo objectForKey:@"bar"];
There are also array and dictionary literals @[…], @{…} and you can also just type @1 to get NSNumber from primitive.
- kemiller 14y agoI'm aware of all that, but of course you DO want to show things to the outside, all the time. I also know about the newer syntax, which is awesome the few times I still dip into ObjC, but I'm more thinking of map/each/select/detect/etc. There are builtin methods for doing those, but their sheer verbosity tends to discourage the sort of free and easy chaining that Ruby encourages. (Some might argue that's a benefit. Not me.) Cocoa is a fantastic system to build on top of. NSDate is MILES better than the Ruby time stuff, for example. NS/UI solid core plus Ruby's flexible syntax and culture of sensible defaults is a marriage made in heaven.
- gdubs 14y ago>> I'm aware of all that, but of course you DO want to show things to the outside, all the time. Well, there's a solid argument to be made in favor of limiting how much internals are exposed to other objects. I personally like keeping my headers as minimal as possible.
- kemiller 14y agoTo clarify: Ruby has public and private. You can control visibility all you want, you just don't have to use a separate header file.