Swit 的字符串处理实在是太让人无语了

[skyline75489]

最近试着用Swift写一个Markdown解析器( https://github.com/skyline75489/Annie ) ，需要大量地使用正则以及字符串处理，Swift需要调用NSRegularExpression来做正则，本身对于字符串的处理又极其不友好。

Python的一个re.match，用Swift写是这样的:

let md:String = "# Hello"

if let re = NSRegularExpression(pattern: "^ *(#{1,6}) *([^\n]+?) *#* *(?:\n+|$)", options: NSRegularExpressionOptions.CaseInsensitive, error: nil) {
let matches = re.matchesInString(md, options: NSMatchingOptions.ReportProgress, range: NSMakeRange(0, countElements(md)))
for match in matches {
let range = match.rangeAtIndex(1)
let start = advance(md.startIndex, range.location)
let end = advance(start, range.length)
let r = md.substringWithRange(Range<String.Index>(start: start, end: end))
println(r)
}
}

为了模拟Python里的text = text[len:]，需要这么写:

text.removeRange(Range<String.Index>(start: text.startIndex, end: advance(text.startIndex,length)))

苍天有眼啊。。。这哪是人类能使用的语言。。。

写了半天的结论就是，现在Swift还是不够成熟，Xcode经常写着写着SourceKit就崩溃。我还是挺喜欢Swift这个语言的，希望苹果能继续努力啊，不要让广大开发者失望。

[otakustay]

基本上静态类型语言都这么写吧……

[hooozer]

嗯，标题关键词拼错，差评。。

[WildCat]

我直接仿照 Ruby 的 Strung.match 写了个 extension ，用得很爽

[skyline75489]

@otakustay 它这个String的下标是String.Index，类似于C++容器的Iterator，但是它没实现隐式转换，没实现运算符重载，导致只能用(Range<String.Index>(start: text.startIndex, end: advance(text.startIndex,length)))这种诡异的写法，而不能直接Range<String.Index>(start:0, end:len)。

相比之下C++的Iterator好用多了。。。

[xuming]

试试exswift

[wuhx]

这是类型安全的代价，好处是很多问题编译时就能发现

[clowwindy]

有人有兴趣一起做一个用 Python 开发 iOS 的框架么？

https://github.com/clowwindy/iOS-Python-Project/blob/master/app/myapp/ui.py#L42

[skyline75489]

@clowwindy clowwindy大神居然回复我的帖子了。。。受宠若惊啊。。。

这个看起来挺好玩的，用什么做到的？使用PyObjc做Bridge?

[clowwindy]

@skyline75489

基于这两个东西改的：

https://github.com/pybee/Python-iOS-template
https://github.com/pybee/rubicon-objc

上面还需要做一层封装，把常用 Framework 的 API 提供出来

[skyline75489]

@clowwindy 我先去学习一下这两个框架试试。要是真能用Python写iOS的话就太幸福了，本来指望Swift能够做到Python那么灵活，现在看来还是有难度。

[xuming]

@clowwindy 这个项目意义何在？
项目挺有意思的！有几点问题探讨一下。
1.性能问题：
从原理看是将整个python环境打包放到了应用中，最终代码还是解释执行的，在手机内估计效率不会高。另外python的全局性解释锁（GIL）使其不能高效的处理多线程。
2.实用性
Python从来都不是以界面见长的，用他开发界面程序还不如原生开发来的方便

我觉得有两个方向或许更值得考虑考虑
1.用Python的语法写然后编译成原生代码
2.更加方便的将python集成进去，提供方便的相互调用机制

PS:不知道集成python这样的解释性语言的应用能否通过审核

[clowwindy]

@xuming

1. 只要不用 Python 语言本身做密集型计算就不会带来性能问题。从我以前的经验来看 CPU 开销大多在苹果的代码栈里，比如布局、绘图、解码，自己写的业务代码没做过这类计算，我们一般在 iPhone 上不回遇到过滤上百 MB 的数据这样的场景。唯一想到可能存在问题的地方就是 GC 影响动画，可能可以通过修改 Python GC 的时机来解决。
2. GIL 对 Python 的影响一直都被高估了，它只锁解释器，iOS 上只有网络和存储需要在非主线程上跑，这些都是非 Python 代码，不会被 GIL 锁住。
3. 苹果的 Foundation 和 UIKit 我觉得是比较恶心的，处理字符串和数组多麻烦我就不说了，对于网络和持久化，如果能尽量绕开选择替代的 Python 方案，比如网络用 requests 持久化用 SQLAlchemy，也会方便很多，甚至可以用后端的业务模块？界面可能绕不开还是得用 UIKit，但其实只是换了个语言，接口都没变。
4. 开发语言限制已经从 App Store 审核方针里去掉了。

最大的工程大概是根据 Objective-C 头文件生成对应的 py stub 文件以便开发时参照和自动补全。

[skyline75489]

@clowwindy 做上层API封装具体需要指做些什么？看起来通过Rubicon已经能够使用UIKit里大家熟悉的API了，还有必要再做高层封装吗？我感觉那样的话可能大家倒不会用了。我看了一下Wax的示例代码，也是直接使用的和OC一样的函数名，没有做二次封装。