Re: including xibs from another project
Re: including xibs from another project
- Subject: Re: including xibs from another project
- From: Luke Hiesterman <email@hidden>
- Date: Wed, 20 Jan 2010 09:28:43 -0800
From the compilers perspective, the pointer could be absolutely any
type - even one that doesn't have an implementation for the given
method. Whether the object responds to the selector is a runtime
question, not a compile/link time one. The method call is compiled to
obj_msgSend or one of it's friends and us linked to libobjc. The
assumption that foo is a pointer to any particular object class or
group of classes is a big one, and can only be validated at runtime.
Luke
Sent from my iPhone.
On Jan 20, 2010, at 8:21 AM, Roland King <email@hidden> wrote:
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