Re: [newbie] tutorial / version of XCode..
Pascal J. Bourguignon
> As an aside, something's been gnawing at my mind: why, in every tutorial,
> does everyone create an object to do what he wants to do? Why not just use
> NSObject? Or does NSObject not lend itself to be used by a programmer?
>
> Your help would be gratefully received.
A farmer notices his chickens are getting sick, he calls in a
physicist to help him. The physicist takes a good look at the
chuckens and does some calculations, he suddenly stops and says
"I've got it, but it would only work if the chickens were
spherical and in a void.".
Any method you would add to NSObject would be available to any object,
of any class. If you added a method -fly, suddenly all your
Elephants, Boxes, Cars, Books, Operations, whatever you have in your
program, would be able to fly.
Worse, if you want to merge the features implemented by different
programmers in a single application, if methods have been added to
common classes, they might clash (if they have the same selector).
Doing that you would lose all the benefit of Object Orientation,
namely encapsulation.
NSObject, and any other framework class, is a global resource, a
global namespace. If you define something here, you will get
collision with other people's code.
--
__Pascal Bourguignon__
yitzhak in eretz (sic)
Clear and comprehensible. Thank you.
Y.
--
Yitzhak Isaac Goldstein
'Only two things are infinite, the universe and human stupidity -
and I'm not sure about the former' ((Albert Einstein)
Charlton Wilbur
y> On 2009-09-13, Pascal J. Bourguignon <p...@informatimago.com> wrote:
>> NSObject, and any other framework class, is a global resource, a
>> global namespace. If you define something here, you will get
>> collision with other people's code.
y> Clear and comprehensible. Thank you.
At the same time, this is precisely what categories are for.
Mr Bourguignon overstates the case slightly: if you define something in
NSObject namespace (or in the namespace of other objects close to the
root of the inheritance tree like NSNumber), you are *very likely* to
get collisions with other people's code. However, this is not to say
that it shouldn't be done, but that it shouldn't be done without a very
good reason and without understanding the ramifications.
It's rather like the rules on code optimization:
Rule 1: Don't do it.
Rule 2, for experts only: Don't do it yet.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
Charlton Wilbur
y> Why does Apple seem to change its XCode interface with each
y> release of Mac OS-X?
Because Apple adds features to Cocoa with each release, and puts
support for the new features into Interface Builder. This requires some
refinement and rearrangement to fit everything in.
If you focus on the concepts rather than on learning where to click,
you'll do better in the long run. The concepts haven't changed, and
once you understand them, it's just a matter of figuring out where Apple
put them in this version.
For the purpose of learning, just make sure the version of XCode and IB
you're using match the materials you're learning from.
Preston
<yit...@yahoo.com> said:
>
> Why does Apple seem to change its XCode interface with each release of Mac
> OS-X?
Xcode's interface has changed little over the years, but Interface
Builder did see a revamp in 3.x when Leopard came out.
>
> I'm slowly but surely (as a hobby) learning Objective-C, and was using
> 'Become an XCoder' but got stuck as XCode under Tiger didn't look anything
> like the examples in the book. Then I updated to 10.6 and decided to go at
> it again. I found this little tutorial..
>
> <http://www.youtube.com/watch?v=y2MSvZT3zWU>
>
> Right at 1:25 minutes, when the author adds a class action to the button,
> he does so in the Inspector, but this option isn't visible in XCode 3.2.
> Fine, I eventually found it in the Library palette, but then at 1:44
> minutes when the author ^ drags a line from the button object to the
> controller and gets a pop-up menu? I don't get that menu. How do I tell
> the button to sendBeep: to BeepController?
If you follow the steps in the video, you should be getting that menu,
but this tutorial does things a little differently than usual in that
it declares the class and actions in Interface Builder first and then
tells Interface Builder to generate a default set of class files based
on those declarations. I think that's confusing for newcomers. It's
more informative to create the class files yourself and let Interface
Builder automatically detect them.
Try creating the BeepController class files in Xcode first. Write the
-(IBAction)sendBeep:(id)sender method and save the files. Then in
Interface Builder, drag out an NSObject and set its class identity in
the inspector to that of the new class you created. If Interface
Builder has properly detected the new class files in your Xcode
project, it will autofill the name after you type the first few
characters. This tells Interface Builder that the object is an
instance of the class you just created--nib files are just an archived
collection of object instances, as if you had created them in code.
Now if you ctrl-drag from a control to your new object, Interface
Builder will display a pop-up list of IBActions it has detected in
that object's class.
Look up the "Currency Converter" tutorial in Apple's online
documentation. It will take you step by step through all of this and
probably be clearer to you than this video. You'll have an "aha"
moment when you figure out how nibs, outlets, and actions work.
>
> As an aside, something's been gnawing at my mind: why, in every tutorial,
> does everyone create an object to do what he wants to do? Why not just use
> NSObject? Or does NSObject not lend itself to be used by a programmer?
>
> Your help would be gratefully received.
NSObject is a root class that Cocoa classes, including yours, are
derived from to behave like proper Objective-C objects. You'll never
use it directly.