On Fri, Jan 23, 2015 at 10:04 AM, Corinne Krych <corinnekrych@gmail.com> wrote:

> On 23 Jan 2015, at 10:00, Matthias Wessendorf <matzew@apache.org> wrote:
>
>
>
> On Fri, Jan 23, 2015 at 9:30 AM, Corinne Krych <corinnekrych@gmail.com> wrote:
> Hello all,
>
> Yesterday I was discussing with Sebi about @objc and how you make a Swift class available in Objective-C
>
> Sebi has one issue, in its Swift protocol he wants to declare longitude/latitude Double and make them optional [1]. Because his protocol is swift only (not inheriting a Obj-c one) he uses @objc and this is when, compiler complains with “Property cannot be marked @objc because its type cannot be represented in Objective-C”.
>
> This issue is well-explain in this stack overflow thread [2]
> One work-around (the one used by Sebi) is to use NSNumber and make then optional.
>
> To echo that issue, yesterday Christos on this thread [3] gave the example of QueryKit which uses pod subspec coupled with some Objective-C re-write classes (seen as temporary) to bridge the gap Swift to Objective-C fro a Swift first library.
>
> As we’re talking about iOS7 support for our Swift libs there are 2 aspect of it:
> - support from obj-c code is one aspect
> - dynamic fwk support as expained in this thread [4] is another one…
>
> All in one, it makes me wonder if it’s worth it… all those hacks in Swift code.
>
> +1
>
> Maybe the option we used for ios-push lib i.e.: having obj-c and swift version of the lib would be a better approach.
>
> that means we need to code the missing parts on our other libs, like http or oauth, right ?
>
>


Yeap, OAuth2 will be a good one to start with…

+1
 
Part of it was already written in objc in 1.6.X code base. It’s based on AFNetworking for the http layer.
Maybe we can keep using AFNet and no need to move ios-http to obj-c

+1000
 



--