Re: including xibs from another project
Re: including xibs from another project
- Subject: Re: including xibs from another project
- From: Roland King <email@hidden>
- Date: Thu, 21 Jan 2010 00:21:03 +0800
You mean FooBar is a class which happens to implement some of the same selectors as Foo, but isn't a subclass of it at all and you can't cast a FooBar* to a Foo* and get anything reasonable and it needs none of the code from Foo. Sure that could happen, dynamic method resolution can do a lot of things, but is it likely, no? Yes if you actually call a class method on the class object Foo you know for definite that you need the Foo code, but if you call the method dogFood: on an instance of a Foo*, it's really mostly likely that it's a Foo* or a normal subclass of a Foo* and you're going to need some or all of the class code for Foo at some point.
A linker which made that assumption would sometimes make a too-large binary with dead code in it. A linker which doesn't add class code unless you call an actual class method and ignores instance methods misses some reasonable and normal cases, like this one. I have a Foo*, I call methods on it, I expect that the Foo code is linked in whether it's all used or not.
On 21-Jan-2010, at 12:00 AM, Luke the Hiesterman wrote:
>
> On Jan 20, 2010, at 7:57 AM, Rick Genter wrote:
>
>>
>> On Jan 20, 2010, at 7:47 AM, Roland King wrote:
>>
>>> ok this makes some sense, there's lots of ways in which I can see dynamic resolution of classes or methods isn't known at link time, KVO, methods composed from strings, I would not expect a linker to figure that out. But that's not where we are in this example, it's a little more direct than that, there's a class Foo and if you call
>>>
>>> [ Foo anyMethod ]
>>>
>>> all the code for Foo gets linked in
>>>
>>> but if you call
>>>
>>> [ foo anyInstanceMethod ]
>>>
>>> where foo is explicitly defined to be a Foo*, it doesn't link it in.
>>
>> Just because foo is declared to be as Foo* doesn't mean that it is. It could be a Bar*, where Bar is a subclass of Foo.
>
> Or, for that matter, it could be FooBar* where FooBar has no relation whatsoever to Foo.
>
> Luke _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden