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 ?
--
Matthias Wessendorf
blog:
http://matthiaswessendorf.wordpress.com/
sessions:
http://www.slideshare.net/mwessendorf
twitter:
http://twitter.com/mwessendorf