Bug#892153: Objective-C libraries (was: Bug#892153: marked as done (RFS: addresses-for-gnustep/0.4.8-3 [RC]))
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.
Reply to: