Hi, For the next release, my objective is to re-implement String, Array and Hash using CoreFoundation. The idea is to have only one implementation for every primitive class, and therefore be able to pass primitive objects from Ruby to Objective-C without having to pay any cost. Basically, String would disappear as a class, and would be an alias to NSString. The whole String interface would be re-implemented on top of NSString, using the CFString API. The same goes for Array and Hash. There are several problems that need to be investigated, such as the new 1.9 i18n strings that can have different encodings, or the fact that Cocoa collections do not accept nil as an element. The new implementation should be as realistic as possible. However I doubt we can keep the C API compatible. At least RSTRING_PTR / RARRAY_PTR will not accept inline array modifications. I will start with Hash first because it's the most simple one. This change will also be interesting performance-wise. We might see some surprises when benchmarking against the original implementation. I suspect the new Array will be faster. Laurent
For the next release, my objective is to re-implement String, Array and Hash using CoreFoundation. The idea is to have only one implementation for every primitive class, and therefore be able to pass primitive objects from Ruby to Objective-C without having to pay any cost.
Basically, String would disappear as a class, and would be an alias to NSString. The whole String interface would be re-implemented on top of NSString, using the CFString API. The same goes for Array and Hash.
As we’ve discussed offline, I’d still love to take a crack at this one. I do wonder what we’ll do with NSStrings, though, since they’re not actually mutable. So many issues. -Ben
On Mar 13, 2008, at 4:04 PM, Benjamin Stiglitz wrote:
For the next release, my objective is to re-implement String, Array and Hash using CoreFoundation. The idea is to have only one implementation for every primitive class, and therefore be able to pass primitive objects from Ruby to Objective-C without having to pay any cost.
Basically, String would disappear as a class, and would be an alias to NSString. The whole String interface would be re-implemented on top of NSString, using the CFString API. The same goes for Array and Hash.
As we’ve discussed offline, I’d still love to take a crack at this one. I do wonder what we’ll do with NSStrings, though, since they’re not actually mutable. So many issues.
We could check for mutability and accordingly raise exceptions in ! methods. Every string created by Ruby would be mutable anyway, we are only talking about non-mutable NSStrings received from ObjC, which I don't think are a big deal. But if we want to be truly compatible on the other side too... we will have to find a solution. Laurent
participants (2)
-
Benjamin Stiglitz
-
Laurent Sansonetti