Swit 的字符串处理实在是太让人无语了
skyline75489 · skyline75489 · 2015-01-09 21:49:42 +08:00 · 5742 次点击这是一个创建于 3590 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近试着用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这个语言的，希望苹果能继续努力啊，不要让广大开发者失望。
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这个语言的，希望苹果能继续努力啊，不要让广大开发者失望。
 |
1
otakustay 2015-01-09 23:41:07 +08:00
基本上静态类型语言都这么写吧……
|
 |
2
hooozer 2015-01-10 00:10:14 +08:00
嗯，标题关键词拼错，差评。。
|
 |
3
WildCat 2015-01-10 00:13:02 +08:00 via iPhone
我直接仿照 Ruby 的 Strung.match 写了个 extension ，用得很爽
|
 |
4
skyline75489 OP @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好用多了。。。 |
 |
5
xuming 2015-01-10 08:04:33 +08:00 via iPhone
试试exswift
|
 |
6
wuhx 2015-01-10 10:08:01 +08:00
这是类型安全的代价，好处是很多问题编译时就能发现
|
 |
7
clowwindy 2015-01-10 20:15:17 +08:00
有人有兴趣一起做一个用 Python 开发 iOS 的框架么？
https://github.com/clowwindy/iOS-Python-Project/blob/master/app/myapp/ui.py#L42 |
|
8
skyline75489 OP |
|
9
clowwindy 2015-01-10 21:35:41 +08:00
@skyline75489
基于这两个东西改的： https://github.com/pybee/Python-iOS-template https://github.com/pybee/rubicon-objc 上面还需要做一层封装，把常用 Framework 的 API 提供出来 |
|
10
skyline75489 OP @clowwindy 我先去学习一下这两个框架试试。要是真能用Python写iOS的话就太幸福了，本来指望Swift能够做到Python那么灵活，现在看来还是有难度。
|
|
11
xuming 2015-01-10 23:03:31 +08:00 via iPhone
@clowwindy 这个项目意义何在？
项目挺有意思的！有几点问题探讨一下。 1.性能问题： 从原理看是将整个python环境打包放到了应用中，最终代码还是解释执行的，在手机内估计效率不会高。另外python的全局性解释锁（GIL）使其不能高效的处理多线程。 2.实用性 Python从来都不是以界面见长的，用他开发界面程序还不如原生开发来的方便 我觉得有两个方向或许更值得考虑考虑 1.用Python的语法写然后编译成原生代码 2.更加方便的将python集成进去，提供方便的相互调用机制 PS:不知道集成python这样的解释性语言的应用能否通过审核 |
|
12
clowwindy 2015-01-11 03:13:29 +08:00
@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 文件以便开发时参照和自动补全。 |
|
13
skyline75489 OP @clowwindy 做上层API封装具体需要指做些什么？看起来通过Rubicon已经能够使用UIKit里大家熟悉的API了，还有必要再做高层封装吗？我感觉那样的话可能大家倒不会用了。我看了一下Wax的示例代码，也是直接使用的和OC一样的函数名，没有做二次封装。
|
Select Language