Sidebar Sidebar
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

macOS Storing a class in a Cocoa collection?

N

Nutter

macrumors 6502
Original poster
Mar 31, 2005
432
0
London, England
Does anybody know a good way to to store the Class type (as returned by +class) in a Cocoa collection?

The best solution I can think of is to create a simple object wrapper to store the variable ... is there a better way?
 
HiRez

HiRez

macrumors 603
Jan 6, 2004
6,250
2,576
Western US
Nutter said:
Does anybody know a good way to to store the Class type (as returned by +class) in a Cocoa collection?

The best solution I can think of is to create a simple object wrapper to store the variable ... is there a better way?
Click to expand...
You could do that, but since each object can retrieve its own class, as you pointed out above, why do you need to store it separately? Just retrieve objects into an id object and call the +class method on the objects in the collection to find out what they are. And use the NSStringFromClass() if you need a string for the class name.
 
K

kainjow

Moderator emeritus
Jun 15, 2000
7,958
7
No need to convert to NSString or write a wrapper. It should work just like a standard object:

Code: 
	NSMutableArray *array = [NSMutableArray array];
	[array addObject:[NSString class]];
	[array addObject:[NSArray class]];
	[array addObject:[NSDictionary class]];
	[array addObject:[NSData class]];
	[array addObject:[NSNumber class]];
 
N

Nutter

macrumors 6502
Original poster
Mar 31, 2005
432
0
London, England
kainjow said:
No need to convert to NSString or write a wrapper. It should work just like a standard object.
Click to expand...

But surely that won't work, will it? Won't the collection attempt to retain the object that I'm adding, causing a crash as there is no class method called "retain"?

I must admit I haven't actually tried this, I just assumed it wouldn't work!

HiRez said:
You could do that, but since each object can retrieve its own class, as you pointed out above, why do you need to store it separately? Just retrieve objects into an id object and call the +class method on the objects in the collection to find out what they are. And use the NSStringFromClass() if you need a string for the class name.
Click to expand...

But I'm not storing any objects, only the classes. It's probably quite an unusual case - I want to store a list of classes associated with particular dictionary keys, so that I can later read a second dictionary and check that the stored objects are of the right class.
 
N

Nutter

macrumors 6502
Original poster
Mar 31, 2005
432
0
London, England
wittegijt said:
[MyClass class] returns the class object. In obj-C a class is also an object (unlike C++). Since it is an object, you can store it in an array. There really is nothing special about it.
Click to expand...

I do understand that, I'm just wondering why the runtime doesn't raise an exception when trying to call the method retain on the class object. Is there a (dummy) class method declared by NSObject called retain? If so, it's not documented. Am I missing something?

Thanks for the link by the way.
 
W

wittegijt

macrumors member
Feb 18, 2007
31
0
Eindhoven
Nutter said:
I do understand that, I'm just wondering why the runtime doesn't raise an exception when trying to call the method retain on the class object. Is there a (dummy) class method declared by NSObject called retain? If so, it's not documented. Am I missing something?

Thanks for the link by the way.
Click to expand...

I'm afraid I don't understand what the problem is. Why would the runtime raise an exception?
BTW: The NSObject protocol does declare retain.

Wittegijt
 
N

Nutter

macrumors 6502
Original poster
Mar 31, 2005
432
0
London, England
The NSObject protocol declares retain as an instance method, not a class method! Or at least it appears to...

The runtime raises an exception when you send a message to a method that doesn't exist. Try it yourself - find one of your own objects, and send a message to invoke an instance method to the class. For example:

[FooClass doFoo];

You will get an exception. However, attempt to call any instance method declared by NSObject and nothing will happen:

[FooClass retain];

Why is that? Is NSObject declaring every single one of these methods as class methods as well?
 
W

wittegijt

macrumors member
Feb 18, 2007
31
0
Eindhoven
Nutter said:
The NSObject protocol declares retain as an instance method, not a class method! Or at least it appears to...

The runtime raises an exception when you send a message to a method that doesn't exist. Try it yourself - find one of your own objects, and send a message to invoke an instance method to the class. For example:

[FooClass doFoo];

You will get an exception. However, attempt to call any instance method declared by NSObject and nothing will happen:

[FooClass retain];

Why is that? Is NSObject declaring every single one of these methods as class methods as well?
Click to expand...

Of course it's an instance method! What would be the use of reference counting a class? There will be only one class object for every class, no? And the [MyClass class] method returns an instance, not a class object!

Wittegijt
 
Krevnik

Krevnik

macrumors 601
Sep 8, 2003
4,100
1,309
Nutter said:
No, [MyClass class] returns a pointer to the class object itself.

I've found the answer: "Instance methods defined in the root class can be performed both by instances and by class objects."

It's annoying that Apple doesn't mention this in the NSObject reference.
Click to expand...

Although, intuitively, this makes a lot of sense.

Instances are objects that follow the protocol laid out by the class. Class objects are also objects, that follow the protocol laid out by the runtime. Class objects can be retained and released, as they are simply objects. But, there might be special behavior so that only the runtime can actually cause a class object to be deallocated. If not, you might be able to have fun crashing an app with:

Code: 
[[NSObject class] release];

When dealing with Obj-C, I find it is better if I think in the Java/C# mindset than the C++ mindset. Objective-C provides a very robust runtime that C++ never thought about providing (since it was a OOP hack onto C to 'go where the business was wanting to go').
 
You must log in or register to reply here.
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.
Top Bottom