On Nov 13, 2013, at 12:08 PM, Erik Doernenburg wrote:

> In Source/OCMock/OCPartialMockObject.m:
> 
> >  
> > -    NSMethodSignature *signature = [[self mockedClass] instanceMethodSignatureForSelector:selector];
> > -    // TODO: below we shouldn't really use getTypeEncoding because that doesn't work for methods implemented with -forwardingTargetForSelector:
> > -	IMP forwarderImp;
> > -	if([signature usesSpecialStructureReturn])
> > -		forwarderImp = class_getMethodImplementation_stret(subclass, @selector(aMethodThatMustNotExist));
> > -	else
> > -		forwarderImp = class_getMethodImplementation(subclass, @selector(aMethodThatMustNotExist));
> > -	class_addMethod(subclass, method_getName(originalMethod), forwarderImp, method_getTypeEncoding(originalMethod));
> > +	const char *types = method_getTypeEncoding(originalMethod);
> > +	/* Might be NULL if the selector is forwarded to another class */
> > +	if (types == NULL) types = [[[self mockedClass] instanceMethodSignatureForSelector:selector] fullObjCTypes];
> Does this really work? A quick test with a method that takes no arguments and returns an object reveals:
> 
> method_getTypeEncoding() returns "@16@0:8"
> fullObjCTypes returns "@@:"
> Are the numbers interspersed with the types relevant for our purposes?
> 
> 
	I'm pretty sure they are not.  The offsets in the types are based on the m68k architecture and have not really been useful ever since.  They still produce the numbers since some parsers expect them to be there, but the numbers themselves are meaningless.  We could change the method to inject some random values I guess but the runtime does not use them, I'm fairly sure.   There is some grumbling in the clang source code about still having to generate the numbers for back-compatibility purposes.   The numberless types seemed to work fine, though I guess it's hard to predict what code out there might read them.

	-Carl