I'm not quite sure what you mean? Is that like the class modelling tool included in Xcode 3/3.1 or something different?
I'm not sure what the class modeling tool is, but what he means is not as applicable to Objective-C as languages like Java and C++ where you can have abstract methods in the parent class that must be overwritten in a child class unless the child class is also abstract . The idea is that you can have a sort of thing that you can't have an instance of, but anything that extends/inherits from that class has access to the methods the parent does define, but must also implement the methods. You cannot actually instantiate a class until all of the abstract methods of the class(es) it extends are implemented. Other methods of the parent can also be overwritten, but they don't have to be.
The most applicable place for this in Objective-C (not sure if that's what the OP is working in, if they are working on C++ this would be a much more desirable feature) is with protocols. For example, if you created a new class, XCode could (but doesn't) allow you to define which Protocols the class will implement, and then give you skeleton methods necessary to implement all of those protocols, so you know right off the bat what you have to do. It would be a time-saver, and is worth a feature request. However, like I said, this is much more applicable in C++ and Java where the concept of abstract classes exists.
I don't know that it would be as useful when you create a class to put skeletons in for every method of the super class, as you may not want to override everything, whereas with abstract you are going to want to override everything (if you want to be able to instantiate this class).
The real drive with abstract classes is to allow a type of some sort. I'm going to be grasping for straws on this example, but we'll say animal just for kicks is your base class. You wouldn't want to just instantiate an animal. There would be very little known about the object, and it would be too vague to be useful. So animal would be abstract, and have fields like weight, length, number of limbs, number of digits, kingdom, phylum, class, order, family, genus, species, etc. that all animals have. It would implement getters and setters for these things, perhaps, and maybe some methods that get information like "canFly" that uses a few different fields (like i said this is a stretch... it might use the "hasWings" field and class equal to Aves, and species not penguin, emu, etc.). Then the class would define some abstract methods like getDescription, eats(Animal), etc. Then for each type of animal you would have a class that inherits from animal. It would override some methods as needed (say canFly now just returns a boolean that is set to true for the Quail class, etc.) and would have to override all of the abstract methods suitably.
I'm guessing no one was really asking for this information, but in my past experience with IDEs these were the cases where the feature the OP is requesting was most valuable.
-Lee
P.S. I know the animal example is somewhat contrived, i was trying to come up with something.
