[Gametes]

Is it possible to "graduate" a class to one of its subclasses, or -- god forid -- move to a parallel class? The latter seems very impossible but I don't see why I can't graduate an NSDictionary to an NSMutableDictionary. IMHO, it should even happen automatically when I call a mutating method on an immutable object.

[Angus_D]

Originally posted by Gametes:
Is it possible to "graduate" a class to one of its subclasses, or -- god forid -- move to a parallel class? The latter seems very impossible but I don't see why I can't graduate an NSDictionary to an NSMutableDictionary. IMHO, it should even happen automatically when I call a mutating method on an immutable object.

I don't really understand what you're on about here. You can get a mutable version of a dictionary using -mutableCopy or +[NSMutableDictionary dictionaryWithDictionary:]...

[Ghoser777]

Eh... graduation isn't all it's cracked up to be. A couple of fancy speeches and an uncomfortable outfit, that's about all you get out of it.

I've never heard of "graduating" a superclass to a subclass before, but Angus-D is right, [NSMutableDictionary dictionaryWithDictionary:immutDict] would be the way to go.

That doesn't seem like such a bad idea though... like, say you have a Shape object and the Shape class has a subclass called Cirlce - wouldn't it be nice to just "graduate" from being a shape to a circle instead of relasing the shape and replacing it with a circle object? Then if the shape object is stored in an array or something, then you wouldn't have to replace the object in the array as well.

Hmmm.... I wonder if this can be accomplished by adding a category to NSObject...

Code:
- (BOOL)graduateObject:(id)obj to Subclass:(Class)subclass;

hmmm...

Matt Fahrenbacher

[Chuckit]

That could only work if the subclass declared no new instance variables. Then I'd imagine you would just have to assign the subclass to isa. Otherwise, though, they wouldn't take up the same amount of space in memory--it isn't possible to cram an NSTextView into the space previously occupied by an NSObject.

[Ghoser777]

Originally posted by Chuckit:
That could only work if the subclass declared no new instance variables. Then I'd imagine you would just have to assign the subclass to isa. Otherwise, though, they wouldn't take up the same amount of space in memory--it isn't possible to cram an NSTextView into the space previously occupied by an NSObject.

Yeah, that's very true... hrm. That probably explains why graduation is implemented

I'm thinking if you're careful that there might be a way to do it, but there would have to be a way to grow the number of instance variables, the same way you could grow the element count in an NSMutableArray... but I think I have officially compared apples and oranges.

Matt Fahrenbacher

[Gametes]

LOL, it's an NSMutableObject, if you think about it. Apple hates it when I write them...

[Angus_D]

Originally posted by Ghoser777:
That doesn't seem like such a bad idea though... like, say you have a Shape object and the Shape class has a subclass called Cirlce - wouldn't it be nice to just "graduate" from being a shape to a circle instead of relasing the shape and replacing it with a circle object?

Why would you have a Shape in the first place when you really want a Circle?

[Chuckit]

Originally posted by Angus_D:
Why would you have a Shape in the first place when you really want a Circle?

For example, in Quark there are three kinds of boxes--a text box, an image box and a plain box. This scenario would most naturally be represented with a TextBox class and an ImageBox class inheriting from a Box class, right? But you can switch among the three at any point, which means you'd have to destroy the Box and put an ImageBox in the same place.

[absmiths]

Originally posted by Chuckit:
For example, in Quark there are three kinds of boxes--a text box, an image box and a plain box. This scenario would most naturally be represented with a TextBox class and an ImageBox class inheriting from a Box class, right? But you can switch among the three at any point, which means you'd have to destroy the Box and put an ImageBox in the same place.

No it doesn't. If the system were properly designed, Box would be an abstract class or an interface (in Java terms), as would Shape be.

Like this:

Code:
Shape shape = new Circle();
Circle circle = (Circle) shape;

Whether this is what the original poster refers to or not I don't know, but in the situation like the poster above described you wouldn't create a meaningless Shape object just to throw it away and replace it with a Circle object (when the Circle is what you wanted in the first place).

As for "growing" an object into a more complex type, I would just implement either a factory method in the target type or create a copy constructor which takes a pointer to the super class type and constructs a valid subtype from that (which will discard the object).