Re: CoreBase toll-free bridging

[Fred Kiefer]

On 14.03.2013 14:15, Stefan Bidi wrote:
> Your suggestion is how toll-free bridging is currently implemented.
> There are no fast-track functions without the ObjC test.  As far as I
> can tell, the overhead isn't that bad.

Sorry, I did not notice that. But then when I looked in CFString.c I 
only found four calls or so, this is really easy to overlook. CFData.c 
seems to be more complete in that respect.

> The only problem is that not every function maps directly to a method,
> so there might some additional swizzling needed to make some of those
> functions work correctly with ObjC objects.
>
> Another interesting articles on toll-free bridging is:
> http://cocoadev.com/wiki/BridgingForFunAndProfit
>
> On Thu, Mar 14, 2013 at 3:42 AM, Fred Kiefer <address@hidden> wrote:
> > On 13.03.2013 09:12, Luboš Doležel wrote:
> > > So guys, what do we do? :-)
> > >
> > > I'd be unhappy if this topic just faded away...
> >
> >
> > Same here :-)
> >
> > We need a solution where Corebase works without base being present. And when
> > base is there it should fit in as well.
> > I read through the documentation at
> > http://developer.apple.com/library/mac/#documentation/CoreFoundation/Conceptual/CFDesignConcepts/Articles/tollFreeBridgedTypes.html
> >
> > We have different options:
> >
> > - Implementing CoreBase on top of base wont work as Stef Bidi pointed out,
> > or rather it only would if we put the full CoreBase into base.
> >
> > - Replacing the base classes with CoreBase ones, as implemented in your
> > changes that started this thread, wont work either. As soon as somebody uses
> > a self implemented NSString subclass that wont be bridgable to CoreBase.
> >
> > - We could make all the CoreBase functions tiny wrappers around Objective-C
> > classes that are independent of base. I think this was the idea I originally
> > proposed when we started out on CoreBase. That way we would be able to pass
> > in base objects into CoreBase functions and things still would work. This
> > would not allow for the special deallocation functions that are possible for
> > many CoreBase data types and would thereby limit the way CoreBase could be
> > used.
> >
> > - The only way that could work all the time is to add a test in each
> > CoreBase function, whether the passed in reference is a CF reference or a
> > real object and dispatch based on that. This is a lot of overhead, but only
> > then we will have toll free bridging.
> >
> > Having decided that I googled once more and found this article:
> > http://www.mikeash.com/pyblog/friday-qa-2010-01-22-toll-free-bridging-internals.html
> >
> > Which just means, I could have saved myself a lot of reasoning, by doing
> > this first :-) And this article even points to one with more details. I
> > think this is the way to go. One downside here is that this means we will
> > need each CoreBase function twice an internal version that contains the
> > current implementation and an external, that checks the passed in reference
> > before calling the internal one. And we will need to figure out a way to do
> > the message send without objc_msgSend() for the old libobjc runtime.