Edited at

Objective-CはSwiftに置き換わるのか?

More than 3 years have passed since last update.

「Objective-CがSwiftに置き換わる」っていうのがピンとこないのです。

それは、Swiftそのものがオープンソースになっても、あまり変わらないと思います。

以下はすごーくざっくりした知識で書いています。


Objective-Cの歴史

そもそもObjective-Cが何なのか、あまり知られていない気がします。

超ざっくり説明すると、AppleをやめたジョブズがApple OSの「次」として、当時としては革新的なオブジェクト指向OSだったNeXTSTEPを生み出しました。NeXTSTEPの存在は後の様々なOSに影響を与えました。OSXやiOS自体、NeXTSTEPの系譜です。

NeXTSTEPはオブジェクト指向のOS・開発環境・開発言語を統合し高い生産性を実現していました。その開発言語がObjective-Cでした。NSのプレフィクスの意味が、NeXTSTEPの略称というのは、比較的知っている人が多いと思います。

そのNeXTで世界初のウェブブラウザWorldWideWebや、世界初のFPSであるDOOMが生み出された…というのはあまり知られてない気がします。今でも公開されているこれらのソースコードを読むと、当然ですがObjective-Cで書かれていて、なかなか感慨深いです。(DOOMは本体はC、開発ツールのみObjective-Cですが)


Foundation

しかし現在において、重要な役割を果たしているのは、Foundationです。

Foundation Framework Reference


Foundation frameworkはObjective-Cクラスの基層を定義します。加えて、有用なプリミティブクラスの集合を提供し、それらはObjective-C言語機能がカバーしないいくつかのパラダイムを取り入れます。Foundationは以下の目標を念頭にデザインされています。


  • 基本的なユーティリティクラスを小さくまとめて提供します

  • 一貫性のある規則を導入することで、ソフトウェア開発を容易にします

  • Unicode文字、オブジェクトの永続化・配信をサポートします

  • 移植性を高めるため、OSレベルの独立性を提供します


Objective-Cの言語仕様は非常にミニマルで、単にSmalltalkっぽいオブジェクト指向ランタイムのあるC言語でしかないです。実は文字列型やコレクションクラスを提供していません。NSStringNSArrayは、Foundation上に実装されています。

実質的に不可分なのでFoundationを含めてObjective-C言語とみている人が多いと思いますが…。

Foundationを経由することで、OSが文字列をどういったバイト列で扱うのかについて無知でいることができ、iOSとOSXという異なるOSで移植性のあるコードを記述することができます。(RosettaとかCarbonとかのなんやかんやを聞く限り、そんな移植性良かったっけ?と思わなくもないんですけど)

更に掘り下げると、FoundationはC言語で書かれたCore Foundationの実装を呼び出しているだけです。NSStringとして定義したクラスは、実行時にはNSCFStringの型になっていることが多いと思いますが、これはCFString(Core Foundationの文字列型、CFはCore Foundationのプレフィクス)とブリッジするために存在するクラスです。


Core Foundation

NeXTSTEPをカーネルとアプリケーションフレームワークに分解・整理した過程で生まれたのがFoundationです。OSXやiOSのアプリケーション構築に利用されるCocoa/Cocoa Touchの土台となっています。

このFoundationは、高い移植性を実現するために、後にC言語で書き直されました。それがCore Foundationです。

Core Foundationを介することでWindowsとMacで同じコードを共有することも可能だと思います。

その実例がWindows版のiTunesだったり、Safariだったりするんだと思います、たぶん。Windows版のiTunesなど使っているなら、CoreFoundation.dllで検索してみましょう。CoreText.dllCoreGraphics.dllCFNetwork.dllなどなど見覚えのあるdllが見つかるはずです。

また、Core FoundationはDarwinの一部としてソースが公開されているので、実装を読むこともできます。


結局のところ、Objective-Cって何?

まとめると、Smalltalkっぽいオブジェクト指向ランタイムのあるだけの、ちょっと強いC言語です。

コアな機能は、移植性のためにC言語で実装されています。それがCore Foundationであり、CocoaやCocoa Touchと呼ばれるアプリ開発用のフレームワークはFoundation上に構築されています。

それが冒頭にある「Objective-CがSwiftに置き換わる」っていうのがピンとこない理由です。置き換わるも何も、もともとObjective-Cは、Foundationを使いやすくするためのガワでしかないと思うので。

Foundationは先に書いたとおり、NeXTSTEP由来なのでObjective-Cと強い親和性があります。これを完全に切り捨てるのであれば、Swiftへ置き換わることもあると思います。


Swift

翻ってSwiftを見ると標準ライブラリがひどく貧弱なのが分かると思います。

Objective-Cとの大きな違いとして、言語仕様として独自の文字列型やコレクションクラスを持っています。

型に厳密なSwiftですが、これらのStringArraySetはFoundationのNSStringNSArrayNSSetとキャスト可能という特性を持っています。両者は、メソッドを見ても全くの別の型です。IntDoubleの間ですらキャスト不可能なSwiftにおいて、この特別措置は異常です。

そして型推論、TupleOptionalEnumなど、非常に魅力的な言語仕様を取り入れている一方で、標準入力やネットワーク、データ永続化などのクラスライブラリは全く整備されていません。ほとんどの場合、標準的な機能の利用にFoundationを利用する必要があり、Swiftらしい記述はほとんどできません。エラー処理は今時ダブルポインタです。

それらが不自然だと思わないでしょうか?

しかしメモリ管理ルールがガベージコレクタではなくARCだったり、文字列リテラルをObjective-Cのセレクタと解釈したり、HogeRefというクラス名は特別扱いする挙動があったり、諸々を統合すると、SwiftはFoundation(Core Foundation)と共存を前提とした言語であると考えられるので、それを踏まえるとそうだろうなーという感じです。

Enumを使ってもっと綺麗なエラー処理を書けるのに」という記事を沢山見るのですが、Foundationの目指すゴール、高い移植性、一貫性のある記述による高い生産性を考えると、Swift以外で書けない特殊な記述が標準APIになる可能性は極めて低いと思うんですけど、どうなんでしょうねぇ。いまのところはCocoaの流儀に倣った方がメンテナンス性は高くなるように思えます。