Paul Wise wrote: > On Mon, Mar 12, 2018 at 2:02 AM, Yavor Doganov wrote: > > If -initWithAddressBook:readOnly: is removed in a new version of the > > library, that's an API/ABI break but again, it won't be reflected in > > the symbols table. In a C/C++ library you'll see a symbol > > disappearing but it won't happen here. So even the secondary reason > > for using symbols files (detecting ABI breaks, although that's really > > a weak test) is not applicable. > > Is there some public indicator of the actual symbols changes? It > sounds like Debian's core dependencies infrastructure needs to be > extended to understand Objective C ABIs.
No, and I don't think there's a bug in the toolchain or some kind of limitation. Every method of every class is avaialble at runtime. Application code can introspect to find out if a method is available, can override a method, swap implementations, etc. The runtime performs lookup whether an object responds to a particular selector by checking the class dispatch table, resorting to the forwarding mechanism. The Objective-C compiler does a very basic job by translating method calls to libobjc function calls; all the queries and decisions which function pointer to execute as the method's implementation are deferred and performed by the Objective-C runtime. Because of the dynamic nature of the language this information is not available at build time. As for public vs. private, methods and classes are private only by convention, the runtime has no way to distinguish them. Using private methods is poor practice but you don't get any penalty like implicit function declaration in C.