Amazon.com Widgets @Class directive question
Welcome, Guest. Please login or register.
Did you miss your activation email?
October 22, 2014, 11:36:11 PM
Home Help Search chat Login Register 
News: Read this please.The Great Kangaroo Escape Looking for reviews of the 4th ed on Amazon!   Twitter:  @skochan
                     

+ Official Forum for Programming in Objective-C (the iPhone Programming Language) - Stephen Kochan
|-+ Old Stuff
| |-+ Chapter Study
| | |-+ Chapter 8 - Inheritance
| | | |-+ @Class directive question
Pages: [1] Go Down
Print
Author Topic: @Class directive question (Read 5070 times)
Mike
Jr. Member
**
Posts: 51


Email




on: March 28, 2009, 09:53:14 AM

Hi All,

Not exactly why I would use a @Class directive.   My question is if I have a XYPoint header and implentation file already defined could I use the @Class directive and be able to use the instance variable and methods of the class?  I was thinking I would try it but not sure how to set it up in COCOA.

Thanks
Mike

Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #1 on: March 28, 2009, 10:22:10 AM

Mike,

The @class directive only tells the compiler that the specified name that follows is the name of a class.  It (obviously) conveys no information about the class itself, namely its methods or instance variables.  In this example on page 169, it suffices in the Rectangle's header file to tell the compiler that XYPoint is the name of a class, as no methods are referenced in that header file.

Cheers,

Steve Kochan
Logged
Mike
Jr. Member
**
Posts: 51


Email




Reply #2 on: March 28, 2009, 01:17:30 PM

Ah... I think I understand.  We did it so that origin could reference an object of type XYPoint. 
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #3 on: March 29, 2009, 01:38:40 PM

Precisely!

Cheers,

Steve K
Logged
MarkReid
Full Member
***
Posts: 173






Reply #4 on: April 17, 2009, 12:15:23 PM

I was having issues with this point too. Is there anything else to learn from program 8.4? I understand what it is doing Ok but I was looking for something more to learn about the @class directive in it.

Am I right in thinking this program is mainly a further illustration if inheritance and not really trying to convey more about how @class works? Because @class does less than I thought it did as I thought it told the compiler all about the class.
Logged
MarkReid
Full Member
***
Posts: 173






Reply #5 on: April 17, 2009, 01:02:04 PM

Not sure I'm getting this one I'm afraid. I'll do my best to explain what I think goes on and you can let me know how far off I am.  Smiley

All this is to do with Program 8.4 on page 168 onwards.

XYPoint.h, XYPoint.m - These are pretty simple just saying there is a class called XYPoint that's made up of two variables, an x and a y. It has accessor methods to set and get the values easier than one and a time.

Rectangle.h - This is where I start getting lost. @class XYPoint is saying, "hey this is a class name, don't freak out when you see it and don't think it's a valid variable name".

Now I don't know how the XYPoint *origin variable fits into this section. A rectangle instance will have a variable known as origin. Is that what it's saying? I suppose I don't understand why Rectangle.h and .m don't need to know about the XYPoint class. They use it to store information so how do they know what it looks like or what it's made up of?

I think I understand setOrigin Ok as it's simply receving an instance of XYPoint as a variable and assigning it to origin. But again how does origin know that it's an x and y point that it's getting?

Think that's enough to be going on with. Perhaps if I understand that it'll make more sense to me. Hopefully you can figure out some kind of question to answer out of that.  Smiley
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #6 on: April 17, 2009, 03:01:00 PM

XYPoint.h, XYPoint.m - These are pretty simple just saying there is a class called XYPoint that's made up of two variables, an x and a y. It has accessor methods to set and get the values easier than one and a time.

Yep, it's pretty straightforward.

Quote
Rectangle.h - This is where I start getting lost. @class XYPoint is saying, "hey this is a class name, don't freak out when you see it and don't think it's a valid variable name".

Yes, you're just telling the compiler that XYPoint is the name of a class.  And if that's all the compiler needs to know (because you're not using any of its methods), then that's all you need to tell it.

Quote
Now I don't know how the XYPoint *origin variable fits into this section. A rectangle instance will have a variable known as origin. Is that what it's saying?

Yes, in 8-4 we're extending the Rectangle class to also have an origin.

Quote
I suppose I don't understand why Rectangle.h and .m don't need to know about the XYPoint class. They use it to store information so how do they know what it looks like or what it's made up of?

The rectangle class doesn't use any of the XYPoint methods in its implementation file, so the compiler doesn't need to know anything more than the fact that XYPoint is the name of a class.

Quote
I think I understand setOrigin Ok as it's simply receving an instance of XYPoint as a variable and assigning it to origin. But again how does origin know that it's an x and y point that it's getting?

It's simply assigning memory addresses in the method.  It doesn't need to know what instance variables are stored in an XYPoint or how big it is.

Hope this helps!

Cheers,

Steve
Logged
MarkReid
Full Member
***
Posts: 173






Reply #7 on: April 18, 2009, 12:13:15 PM

Thanks, that helps a lot. I think I'm just having trouble grasping it in my mind. That the rectangle class only needs to know the name of the class because it has some methods that point to those type of instances. At least I hope that's a better description of why the @class directive is used.

I can only assume that the more I get used to it being used then I'll simply get used to seeing it that way. Just feels odd not doing it the way it has been before for the moment.

Thanks Steve.
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #8 on: April 19, 2009, 07:59:20 AM

The @class directive doesn't get used that much, so don't worry about it.

Cheers,

Steve Kochan
Logged
MarkReid
Full Member
***
Posts: 173






Reply #9 on: April 19, 2009, 08:38:14 AM

The @class directive doesn't get used that much, so don't worry about it.

That's a relief, don't think my brain could deal with the complexities of it all. lol
Logged
Nathan187
Newbie
*
Posts: 12






Reply #10 on: July 06, 2009, 10:15:40 PM

Hey there.  I picked up your book the other day and I have enjoyed it so far.

I too am stuck in Chapter 8 with the @class directive topic.  It's a little frustrating because first off, just about every book that discusses OOP...they use the shape/rectangle examples or the cars.  I wish there were more real world examples than the ones that have been around since the beginning topics of OPP.

I am in Chapter 8 and the @class directive topic is not discussed in depth and the example is lacking.  I still would like to know when you want to do this and would like more examples. (one  or two)

I know that in .NET (C# and VB.NET)...I have created classes that has properties that are classes and this is pretty straight forward.  The message of "informing the complier not to import all the information about the class" is still vague.  Why?  Is it because we still have to worry about memory allocations?  Is it because it's not pretty? 

You can google search @class directive + objective-c and they all give the same standard definition.  Yet there are no real examples.  It's frustrating.
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #11 on: July 07, 2009, 01:46:42 AM

As noted in the text, you use the @class directive when you only need to tell a compiler that a identifier is the name of a class, and it doesn't need to know anything else (such as its methods).  You can completely ignore its use if you like and just import the class header file whenever you need to reference a class.

To find other examples, you can look in the Foundation framework header files; it's used in about 100 of them.

Cheers,

Steve Kochan
Logged
Nathan187
Newbie
*
Posts: 12






Reply #12 on: July 07, 2009, 08:27:52 PM

Thanks for the quick reply and help.

have a good one
Logged
tslining
Newbie
*
Posts: 5


Email




Reply #13 on: March 17, 2010, 08:32:56 PM

In 8.5b on pages 174 and 175, you say Oops! because a method was used from XYPoint and now you need to replace the @Class directive with #import "XYPoint.h".  However, I found that I could retain the @Class directive and use the #import "XYPoint.h" in the corresponding Rectangle.m implementation file where it would be closer to the newly added method.  Is that okay? And is one way better than another?

When you override the inherited dealloc method later in the chapter and add a release for the origin object you allocated from the XYPoint class, doe this method actually get called in the main?  Is that part of [pool drain]? Or does it just sit in the implementation?  I've been wondering that ever since I finished this chapter.  I guess my question is where does the deallocation method get called in programs?  I assume deallocation goes on in every program somewhere.
Logged
skochan
Administrator
Hero Member
*****
Posts: 3114







Reply #14 on: March 19, 2010, 10:34:25 AM

It's not important whether you explicitly import the header file or rely on the fact that it's imported inside another file that you import.

As you'll learn in the chapter on memory management, dealloc gets called when an object is to be destroyed.   If that object has been added to the autorelease pool (again, discussed in greater detail in Chapter 17), that may occur when the pool gets drained.  

Cheers,

Steve Kochan
Last Edit: March 19, 2010, 11:12:58 AM by skochan Logged
Pages: [1] Go Up
Print
Jump to:



Login with username, password and session length

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!
Entire forum contents (c) 2009 classroomM.com. All rights reserved.