OK, here I'm replying to my reply to a post of mine. Pretty solipsistic... Never mind me.

One could argue that automating the generation of delegated methods should give off some pungent code-smell... Why? Because the only rationale for it is for the delegating class to be able to "track" the delegate class's API automatically, but if that's the case, maybe the delegating class should be inheriting instead. In other words, one could argue that the portion of a class A's API that is delegated to another class B should be decided by the designer of class A, irrespective of the changes in class B's API. (Of course, class B's API could shrink, which could in turn break some delegated methods, but IMO it is far more likely that, if it changes at all, the API of class B will grow, not shrink.) Therefore, instead of having class A automatically figure out which methods to delegate to the delegate class, these methods should be hard-coded in the definition of class A. This obviates the problem of distinguishing those functions in the delegate class's and its parents' symbol tables that belong to the delegate class's API from those that don't...