tive-C最令人深恶痛绝的九大特性
实在有点太过特异
tive-C中的字母“C”代表的就是C语言,这一点与“t”中的“Java”完全不同。无论是指针、整数还是括号,所有表达方式都与C非常相近。但二者之间的共同点也就仅限于此了。
tive-C的拥护者们坚持认为tive-C属于C语言的一种规则严格的超集:如果大家能够在C语言中实现某些功能,那么也应该可以在tive-C中加以重现—不过反过来却未必奏效。因此大家可能需要考虑,“我到底应该使用tive-C方法进行描述,还是选择C语言?”实现对C程序的可移植性需要我们以审慎的态度进行深入考量。
除此之外,对于这样一种超集而言,所有声明几乎都需要以排列方式进行。再以后缀为例:C代码保存为文件后扩展名为.c,而tive-C文件的扩展名则为.m。
它仍然基本上属于传统的C语言
大家基本上不可能在tive-C中获得太多来自面向对象的优越特性。总体而言,tive-C更多地是一种针对大型系统的代码组织方式,而非编写优质代码的方式。我们仍然需要负责处理指针、仍然需要负责追踪内存。C语言程序员们喜欢把这些软件称为“可移植汇编代码”,而这一点对于tive-C也同样适用……当然,大家只能把这些代码从Mac移植到iPad当中。
充斥着八十年代风格
灯笼裤、爆炸头、电影《早餐俱乐部》—再加上NeXT设备:tive-C就像是编程语言世界中的一部时光机器,把我们带回上世纪八十年代那段疯狂的岁月。粗犷的风格构成了tive-C的一切。最初出现在Lisp中的垃圾收集机制可谓绝妙的想法,Java早在多年之前就已经将其纳入自身,但tive-C直到2006年才对其敞开怀抱。iOS甚至直到现在还没有获得垃圾收集机制,因为没人希望iPhone因此遭遇卡顿。好吧,至少tive-C还没老旧到Pascal或者Ada那种程度。
标点符号
炫酷的现代技术青年已经能够通过编写Python、Ruby以及Coffeet代码构建起价值数十亿美元的企业,但他们不需要跟括号、中括号以及大括号打交道。但在编写tive-C代码时,我们却被迫使用着几乎所有标点符号。冒号、“@”符号乃至星号,好像没有哪种符号是tive-C用不到的。
复古的语法风格
tive-C的语法跟可口可乐拥有诸多相似之处:它们都曾在上世纪九十年代试图推进其现代化进展,但却始终未能成功。因此大家可以直接忽略苹果在1997年着力推荐的所谓简洁“现代”语法。我们更倾向于使用“经典”语法,正如大家更青睐可口可乐的经典瓶罐一样。平心而论,苹果当初作出的努力其实值得赞赏,其中摒弃了额外的标点符号,而且能在无需解析的前提下让内容更易于阅读。但如今这些成果已经被彻底遗忘在历史的垃圾堆中,再也无人问津。
缺乏命名空间
Java拥有命名空间,但tive-C却没有。不过大家可以通过在名称之前添加大量前缀来构建自己的命名空间,这是完全可行的。需要注意的是,不要使用“NS”前缀,因为这会与苹果的命名空间发生冲突。作为NeXTstep的组成部分,苹果的命名空间倒是始终拥有旺盛的生命力。
只能运行在苹果自己的宇宙当中
被迫每天驾驶保时捷当然不是什么坏事,但生活仍然需要多样性作为重要调剂。更重要的是,iPhone并不是世界的中心、我们不可能完全以它为中心规划生活与工作。如果大家选择在Windows或者Linux业务环境工作,那么请忘掉所有与tive-C相关的扩展知识—理由很简单,这些技能完全无用武之地。
可移植性的价值不容忽视。苹果(以及iPhone用户)最值得庆幸的一点在于,苹果的产品真的非常出色—它们非常强大,足以吸引人们利用tive-C重新编写自己的现有软件方案,只有这样开发者才能最大程度把自己成果运行在无数消费者手中的设备上。
(备注:通过对gcc、Cygwin以及GNUStep的深度组合,大家也有机会在其它环境中使用tive-C,但要完成这项任务各位需要内心坚强、毅力拔群。)
我们惟一的选择就是Xcode
尽管还不至于像毛泽东之于新中国以及亨利?福特之于福特公司那么夸张,但在tive-C的世界中,大家真的只有一种选择。为什么你非要与众不同呢,同志?
公平地讲,目前市场上已经出现了一些开源堆栈,但大家使用这类方案的频率要远远低于Xcode。
苹果的“独裁统治”
如果领导者能为产品线带来美好的发展前景,那么独裁统治倒是不一定算坏事。毕竟苹果这位暴君拥有出众的品位以及卓越的产品设计方案,在这方面苹果甚至比其它所有同业企业加起来还要强大。不过对于追求自由的人们来说,苹果仍然是阻碍大家实现理想的最大难关。
想要发出超过一百份自己开发的iPhone应用副本?赶紧打消这个念头。想要在用户界面中加入一些“不同的想法”?请回去认真阅读苹果提供的用户界面设计指南。我们根本不能在无视苹果许可的前提下作出任何变通,因为苹果利用强大的加密机制将一切牢牢锁定—并通过残酷的专制政策为其加上第二道保险。