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.