On Fri, Jan 23, 2015 at 10:04 AM, Corinne Krych <corinnekrych(a)gmail.com>
wrote:
> On 23 Jan 2015, at 10:00, Matthias Wessendorf <matzew(a)apache.org> wrote:
>
>
>
> On Fri, Jan 23, 2015 at 9:30 AM, Corinne Krych <corinnekrych(a)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
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf