oc 与 smalltalk 的故事

给你 C 语言，如何实现一个 Objective-C？

一个OC的编程者的内功有多深厚，就是要看编程者能把 “给你 C 语言，如何实现一个 Objective-C？” 这个问题答到什么程度。是的OC就是C的超集，而这是为什么，则要牵扯到一个历史悠久的语言SmalkTalk.

Smalltalk 是世界上第二个面向对象的语言。（很惋惜因为编译速度慢的缘由，它最后仍是被抛弃），然而它的思想则对以后的编程语言有着超前的指导做用。

1. 基本思想一：彻底的面向对象。万事万物都是对象，比Java还要完全的面向对象，包括数据常量也是对象。

2. 基本思想二：一切行为（也就是java中的方法），再也不理解为方法调用，而是理解为向一个对象发送消息，也就是向一个对象发送一条命令，这个消息命令也能够带参数。
   而OC 的发明者 Brad Cox 和 Tom Love 在当时主流且高效的 C 语言基础上，借鉴 Smalltalk 这两个思想一想要搞出一个易用且轻量的 C 语言扩展，但 C 和 Smalltalk 的思想和语法格格不入，好比在 Smalltalk 中一切皆对象，一切调用都是发消息：

233 log

再好比用一个工厂方法来实例化一个对象：

p := Person name: 'sunnyxx' age: 26

在当时来看，一个具备面向对象功能的 C 语言真的是很是有吸引力，但必须得解决消息语法的转换，因而乎他们开发了一个 Preprocessor，去解析 Smalltalk 风格的语法，再转换成 C 语言的代码，进而和其余 C 代码一块儿编译。这个过程和如今 JavaScript 里的 CoffeeScript、JSX 很类似，构建一个 DSL，用转化器转化成原始语言的代码。

然而如今问题来了， Smalltalk 语法里面又是空格、又是冒号的，万一遇到个什么复杂嵌套调用，语法解析多难写呀，因而乎他们想，既然什么花括号 大括号都有了，那只好把消息两边加个中括号吧 ，这样 Parser 写起来简单多了呢对吧：

[Person name:"sunnyxx" age: 26];

这就造就了 Objective-C 奇怪的中括号、冒号四不像语法，这怎么看都是个临时的方案，但在当时多是惟一方法，借用已有的 C 的编译器比重造一个成本低多了，并且彻底兼容 C 语言。随着这几年 Apple 开发的火热，Objective-C 愈来愈成为 Apple 不爽的地方，先是恨透了在 GCC 上给 Objective-C 加支持，本身重建了个 Clang，后是干脆从新发明了个 Swift 来完全代替，用 30 年的时间终于还完了这个技术债。

好的，虽然有了个 Preprocessor，但只能作到把 Smalltalk 风格的代码分析并转译成 C，还须要解决两个问题：

1. 语言上实现一个 OOP 对象模型

2. 将 Smalltalk 风格的 Message 机制转换成 C 函数调用

对象模型的设计倒很省事，直接照搬 Smalltalk 的就行了：如 Class / Meta Class / Instance Method / Class Method 这些概念，还有一些关键字如 self / super / nil 等全都是 Smalltalk 的。这步转换在 Preprocessing 过程当中就能够完成，由于重写后的 Class 就是原本来本的 C 语言的 Struct，只须要按 Smalltalk 中“类-元类”的模型设置好便可，无需额外的支持。

消息机制就不同了，要实现向一个 target ( class / instance ) 发送消息名 ( selector ) 动态寻找到函数实现地址 ( IMP ) 并调用的过程，还要处理消息向父类传递、消息转发（ Smalltalk 中叫 “Message-Not-Understood”）等，这些行为没法在 Preprocessing 或 Build Time 实现，须要提供若干 运行时 的 C 函数进行支持，全部这些函数打个包，便造成了最原始的 Runtime 。

因此最初的 Objective-C = C + Preprocessor + Runtime

这样的的话，大概能够把OC上全部的类理为它们都是实例。而为何乔布斯会选择OC作开发语言，由于这自己就是在高级语言身上再封装了一层的语言。则会让开发者学习成本更低，更多开发者愿意投身于iOS应用的开发。而如今的Swift 的想法也是如此，让语言更简单，让编程更容易。推出workplace 这玩意来辅助也是如此。