I'd like to see more of this type of thing. When learning a new language, I don't need an introduction to the if statement or while loops, yet in the interests of completeness many programming books include a thorough (and mind-numbing) guide to them. For some readers that's called for, but many of us are stuck reading about concepts we're already comfortable with. I'm concerned that if I don't read everything, I'll miss out of some bizarre quirk of the language, so I'm reluctant to skim, but this gets in the way of what I'm really trying to achieve - using the language to make cool stuff.
Writers of programming language books take note: I'm generally not interested in the tool. Tools are boring. No really, they are. Making cool stuff and solving hard problems is interesting and fun. Get the tool out of the way so I can get things done.
Agreed. I wrote a couple-page cheat sheet on Objective C, and since I've made a twice-yearly ritual out of forgetting Objective C, it's come in handy. Repeatedly.
"The equivalent to Java’s this is pretty much self."
Well no, the difference (inside a class) of:
this.foo = myshinyobject
and
foo = myshinyobject
is nothing in Java. In Objective-C,
self.foo = myshinyobject
and
foo = myshinyobject
are different. Particularly with regards to the @property (retain) magic; if you forget self.foo and use foo, then myshinyobject might get garbage collected. Which is not what you'd expect with a retained property.
Well, on iPhone, it would get deallocated with the next pool drain, not garbage collected (since garbage collection does not exist for iPhone as of now.)
foo = myshinyobject is ok if you use instantiate it like [[SomeClassThing alloc] initetc] rather than one of the convenience methods like [SomeClassThing thing] since those are supposed to be returned with a retain count of 0.
[+] [-] concretecode|16 years ago|reply
Writers of programming language books take note: I'm generally not interested in the tool. Tools are boring. No really, they are. Making cool stuff and solving hard problems is interesting and fun. Get the tool out of the way so I can get things done.
[+] [-] tptacek|16 years ago|reply
[+] [-] dejb|16 years ago|reply
- You have to use Xcode as your IDE.
- You have to use the Objective-C language
- You have to manage your memory manually.
- You have to have a certificate in order to sign your code to make it work on a device.
- You have to pay a yearly fee ($99) to get the ability to create such a certificate.
- You’ll have to provide various pieces of information, and enter into a distribution contract with Apple.
- Apple has to approve your app before it goes onto the App Store.
Seems a little restrictive. Imagine the antitrust concerns this would bring up if the platform actually did become dominant.
[+] [-] tptacek|16 years ago|reply
[+] [-] jlongster|16 years ago|reply
http://jlongster.com/blog/2009/06/17/write-apps-iphone-schem...
[+] [-] TJensen|16 years ago|reply
[+] [-] cdr|16 years ago|reply
[+] [-] einarvollset|16 years ago|reply
Well no, the difference (inside a class) of:
this.foo = myshinyobject
and
foo = myshinyobject
is nothing in Java. In Objective-C,
self.foo = myshinyobject
and
foo = myshinyobject
are different. Particularly with regards to the @property (retain) magic; if you forget self.foo and use foo, then myshinyobject might get garbage collected. Which is not what you'd expect with a retained property.
[+] [-] tumult|16 years ago|reply
foo = myshinyobject is ok if you use instantiate it like [[SomeClassThing alloc] initetc] rather than one of the convenience methods like [SomeClassThing thing] since those are supposed to be returned with a retain count of 0.
I forgot what I was getting at.
[+] [-] igorgue|16 years ago|reply