NSJSONSerialization and bridging


(Ian Partridge) #1

Hi, I've been reviewing the current status of NSJSONSerialization.

There is an implementation of JSONObjectWithData() and some tests, but
dataWithJSONObject() is unimplemented.

One thing I noticed is that the signature of JSONObjectWithData() has
been modified so it returns Any instead of AnyObject. I guess this is
to allow bridging to stdlib types like Dictionary and Array?

Should a future implementation of dataWithJSONObject() accept Any
instead of AnyObject to match? What are the consequences for
compatibility with existing code that uses NSJSONSerialization?

Finally, is there any progress to report on the bridging issue? The
lack of bridging between stdlib and Foundation types on Linux is a
pain point at the moment.

Thanks for your time!

···

--
Ian Partridge


(Tony Parker) #2

Hi Ian,

We haven’t really made any progress in this area, unfortunately.

It would be awesome if someone could take up the banner of getting bridging to work on non-ObjC platforms. That would make this performance problem on Linux significantly less burdensome.

- Tony

···

On Mar 4, 2016, at 9:24 AM, Ian Partridge via swift-corelibs-dev <swift-corelibs-dev@swift.org> wrote:

Hi, I've been reviewing the current status of NSJSONSerialization.

There is an implementation of JSONObjectWithData() and some tests, but
dataWithJSONObject() is unimplemented.

One thing I noticed is that the signature of JSONObjectWithData() has
been modified so it returns Any instead of AnyObject. I guess this is
to allow bridging to stdlib types like Dictionary and Array?

Should a future implementation of dataWithJSONObject() accept Any
instead of AnyObject to match? What are the consequences for
compatibility with existing code that uses NSJSONSerialization?

Finally, is there any progress to report on the bridging issue? The
lack of bridging between stdlib and Foundation types on Linux is a
pain point at the moment.

Thanks for your time!

--
Ian Partridge
_______________________________________________
swift-corelibs-dev mailing list
swift-corelibs-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-corelibs-dev


(Dave Grove) #3

Hi Tony,

  I'd be happy to be some of the development "muscle" to help execute a
plan, but I don't yet have the overall grasp of the Swift implementation
needed to propose a plan.

  I think the libdispatch import/object model task I'm working on now
is probably a useful warmup exercise, but even after that is done I expect
I'll need some pointers on how to tackle the bigger problem of bridging in
general.

  Is there are chance there is a design worked out for bridging
alternatives on Linux that could be shared?

thanks,

--dave

···

swift-corelibs-dev-bounces@swift.org wrote on 03/04/2016 05:44:31 PM:

We haven’t really made any progress in this area, unfortunately.

It would be awesome if someone could take up the banner of getting
bridging to work on non-ObjC platforms.


(Tony Parker) #4

Hi Dave,

>
> We haven’t really made any progress in this area, unfortunately.
>
> It would be awesome if someone could take up the banner of getting
> bridging to work on non-ObjC platforms.

Hi Tony,

I'd be happy to be some of the development "muscle" to help execute a plan, but I don't yet have the overall grasp of the Swift implementation needed to propose a plan.

I think the libdispatch import/object model task I'm working on now is probably a useful warmup exercise, but even after that is done I expect I'll need some pointers on how to tackle the bigger problem of bridging in general.

Is there are chance there is a design worked out for bridging alternatives on Linux that could be shared?

thanks,

--dave

Great! I’ll try to summarize some of the issues as I understand them. We can follow up later once you’ve started.

To simplify it to one sentence: The standard library and sometimes the compiler conflate the concept of “presence of the Objective-C runtime” with “presence of Foundation.”

Take a look at this file:

https://github.com/apple/swift/blob/master/stdlib/public/core/BridgeObjectiveC.swift

The entire thing is #ifdefed out on non-ObjC runtimes. Now, it’s true that without the ObjC runtime we do not have autorelease — but we could still convert from NSArray (reference) to Array (struct). Here is another part to it:

https://github.com/apple/swift/blob/master/stdlib/public/core/ArrayCast.swift
https://github.com/apple/swift/blob/master/stdlib/public/core/SwiftNativeNSArray.swift

Some of the bridging logic is done via conformance to a protocol that is known to the compiler (_ObjectiveCBridgeable). Some of it is Swift subclasses of Foundation types like NSArray that are used in the implementation of that protocol.

Now, one could imagine some future where we don’t need bridging because everything is implemented in Swift. However, in order to get something going without having to rewrite the world (and also to leverage good code that we know works the same on all platforms), we started with existing C code in CoreFoundation. When CF creates a CFArrayRef and returns it to the Swift code, we are faced with the same bridging problem we have on Darwin — CFArray is a fundamentally different representation than a ‘native’ Swift Array. Do we pay an O(n) conversion cost, or do we sometimes choose to back the Swift array with the CFArray? On Darwin we sometimes back it with the NSArray; especially when the contents are heterogeneous. On Linux we have no choice and we have to construct a new Swift array each time.

I don’t want to create a sweeping new design for bridging. I think we should just make the environment as similar as possible on Darwin and Linux. This means finding out which things are truly not possible without Objective-C (AutoreleasingUnsafeMutablePointer, for example, which we’ve been excising from our swift-corelibs-foundation API) and separating them from things which are more about type conversion.

It could be the case that we want to put the bridging logic on Linux into swift-corelibs-foundation instead of the standard library. I’m ok with that. On Darwin, the SDK is present which makes it easy to link Foundation (it’s always there). This is trickier in the Linux build environment.

There may be some tricks that the standard library uses (built-ins, etc.) that are not possible to use outside of it, though, so we may need to have some thunks there.

So in summary: no grand re-design; we should just try to get our existing design to work on Linux as closely as we can to how it works on Darwin.

- Tony

···

On Mar 5, 2016, at 7:12 AM, David P Grove <groved@us.ibm.com> wrote:
swift-corelibs-dev-bounces@swift.org wrote on 03/04/2016 05:44:31 PM: