The objective-c language at the time of this writing has no defined standard, to my knowledge. Thus, while it is still open, I will make a proposal to the language. This will not alter the language in such a way that existing programs will break; however, it will offer a new way to solve certain problems that may create much more efficient programs. I would like to propose what I call "Dynamic Inheritance." Dynamic Inheritance is in most simplest terms the alteration of inheritance at runtime for individual objects. For this, a single syntactic augmentation is needed. In theory, it is impossible to inherit the same object in the inheritance hierarchy more than once. This would create circular inheritance which would create an infinite compiler or runtime loop. Even if it did not, it would be impossible to identify the beginning and end of the list. Thus, we can identify where we want to change inheritance by giving the name of the class to replace. By giving this name paired with the new class on calls to class members, we can dynamicly alter inheritance at runtime for specific cases. The syntactical change would be to augment the message passing of class members to allow an *optional* pair to indicate the change. Currently, calling +(id)alloc is done as follows: [myObject alloc]; To achieve Dynamic Inheritance, the class name would have to include the old/new class pair to indicate the inheritance switch. Let's assume that myObject inherits from myRootObject; and that we wish to inherit from myDebuggingRootObject instead. Our new syntax may look as follows: [myObject::myRootObject:myDebuggingRootObject alloc]; The above would make the call to +alloc as if myObject had inherited from myDebuggingObject. I suggest double colons for readability only, rather than for ease of parsing. The below message is functionally equivalent to the original [myObject alloc]: [myObject::myRootObject:myRootObject alloc]; The difference would be that it would do a very large reflexive assignment (a = a), whereas the original line (which would still be valid) would not. Let us now assume that three objects inherit (from left to right) in the following way: Object:myBaseObject:myString:myMutableString Object:myNewBaseObject Object:myBaseObject:myString:myUTF8String We could replace myBaseObject in the hierarchy with the following syntax and get the given inheritance: Code: [myMutableString::myBaseObject:myNewBaseObject alloc]; Result: Object:myNewBaseObject:myString:myMutableString Similarly, we could replace myString with the following syntax: Code: [myMutableString::myString:myUTF8String alloc]; Result: Object:myBaseObject:myString:myUTF8String:myMutableString Up until now, I have only discussed altering the hierarchy in one place. To do two places, I would suggest using another ::obj:replacement appended to the end of the first: Code: [myMutableString::myString:myUTF8String::myBaseObject:myNewBaseObject alloc]; Result: Object:myNewBaseObject:myString:myUTF8String:myMutableString These pairs would be parsed left to right as applied; the ::myBaseObject:myNewBaseObject couplet would be applied to myMutableString::myString:myUTF8String after myString was replaced with myUTF8String. It may also be useful to replace the inheritance "permenantly" during the run of a program; however, this would require the following design decisions to be made: 1. Do we replace existing objects, or just replace for NEW objects? I say just for new objects, because the existing objects may or may not be made with the intent of having the current default state. Also, changing inheritance in a threaded environment is far too complex to muck about with in the runtime; but that's besides the point. 2. How do we make this replacement happen? I suggest null message: [myObject::myBaseObject:myNewBaseObject] I have been lead to believe that this is non-trivial to implement; however, it is possible. It is up for your review. I would like to note that I believe this may be useful; however, I have a specific agenda in mind which provides exactly one case in which this would be useful. Thus, I can only comment that far.
Zem, can you have a look at this bug, and take care of this? For instance, confirming it would be a first good step.
Confirmed, but really we should standardize the language first.
Hmm, there is one issue with this proposal is that the classes better have the same elements, otherwise this will not work. This also very runtime dependent so the code for the GNU runtime will be different than the code for the NeXT Rutime. I might be able to get an implemention for the GUN runtime done next week but I have other bugs to look though still and this is an enhancement at that.
This proposed enhancement seems to be a major change to the language! :-) It basically would mean that every object has a customized class hierarchy. So, when a message is sent to the object, the object's custom class hierarchy would need to be traversed - instead of the standard one. (that would indeed complicate messaging quite a lot) When an instance variable of the object is accessed, again the object's custom ivar list would need to be examined to determine the offset of that specific ivar ... instead of using a standard ivar/offset information for all objects. (again this would indeed complicate instance variables quite a lot). I suppose my point is that this object-dependent class hierarchy is not just an "enhancement" - it is so radical that it would basically transform Objective-C into another language (it's a nice idea though!). ;-) The simpler version of all of this is to be able to replace a class with another one. So, you'd replace 'myRootObject' with 'myDebuggingRootObject' and that would happen everywhere in your application for all the objects. This is called 'poseAs:'. It is clearly much easier to implement than custom replacement of classes for a single object, but it is still quite hard. So hard tha Apple removed it from their runtime and deprecated it. It's no longer available there and probably will be removed from the GNU runtime too. Anyway, if you're interested in this dynamic modifications of class hierarchies, you may want to look into up (and maybe open up a new issue on that). I'd like to close this issue just because the enhancement proposed is too radical. ;-) Thanks