gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreBase toll-free bridging


From: Stefan Bidi
Subject: Re: CoreBase toll-free bridging
Date: Thu, 14 Mar 2013 08:15:43 -0500

Fred,
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.

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.
>
> Fred
>
>
>
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev



reply via email to

[Prev in Thread] Current Thread [Next in Thread]