DEV Community 👩‍💻👚‍💻

SUZUKI Tetsuya
SUZUKI Tetsuya

Posted on

Objective-C 䟛逊

※この蚘事は 2015幎12月24日 に Qiita に投皿したものです。

䞖間はクリスマスモヌドだず蚀うのに、蟛気臭いタむトルですみたせん。「勝手に殺すな」ずか「お前は䜕様だ」などずなんだか怒られそうです。「喪倱感で胞がいっぱい」だずか「 Objective-C はただただ䜿える蚀語です」だずか、そういう感傷もありたせんし、䞻匵もしたせん。「いい蚀語だず思うし奜きだけど、結局 Mac OS X や iOS のアプリケヌション開発以倖に掻甚しようずトラむしたけどできないたた Swift が発衚されたなヌ」ず思っおいお、なぜ掻甚しにくかったのかを敎理しおみようず考えたした。ですので、「 Objective-C 栄光の歎史」を語るこずはありたせん。䜓隓しおないし。知らないし。

それから、ここでは蚀語ずしおの Objective-C を扱いたす。アップルのフレヌムワヌクや iOS アプリケヌションの開発ツヌルの䞀郚ずしおの話ではないので、これを読んでも iOS アプリケヌション開発の手助けにならないず思いたす。

バッドノりハりの終焉

Objective-C 2.0 以前

Objective-C 2.0 以前は、アップルのフレヌムワヌクを䜿っおプログラムを曞くのに守るべき䜜法むディオムがありたした。いく぀か挙げおみたしょう。

  • オブゞェクトの生成: alloc -> init の連続したメッセヌゞを送信する。
  • オブゞェクトの初期化: init メ゜ッドを実装し、その䞭で super に察しお init メッセヌゞを送信する。
  • メモリ管理: retain/release でカりントを増枛させる。
  • オブゞェクトの解攟: dealloc メ゜ッドを実装し、むンスタンス倉数に release メッセヌゞを送信埌、 super に dealloc メッセヌゞを送信する。
  • むンスタンス倉数ぞのアクセス: getter/setter を実装する。
  • コレクション芁玠のむテレヌション: Enumerator オブゞェクトを介しお行う。

これらの䜜法は、文法や蚀語仕様ではわかりたせん。ドキュメントを読む必芁がありたす。べ぀だん䞍思議なこずではなく、どんなラむブラリにも順序立おお行わなければならない凊理はありたす。

アップルのフレヌムワヌクを陀くず Objective-C の仕様は極めおシンプルで、ルヌトクラスの Object ずその他䞀぀か二぀のクラスず、メッセヌゞ送信機構皋床です。アップルのフレヌムワヌクではこのルヌトクラス Object は䜿われおおらず、オブゞェクトの生成、解攟凊理からしお同フレヌムワヌクで実装されおいたす。それくらい玠っ気ない代物ですから、同フレヌムワヌクを䜿うためには、たず䞊蚘の䜜法を知るこずから始たりたす。

「 Objective-C はシンプルな蚀語です」ずの説明は間違っおいないず思いたすが、じゃあ iOS アプリケヌションの開発を即座に始められるのかず蚀うず、倧抵の人は難しいでしょう。アップルのフレヌムワヌクである Cocoa は「 NeXTSTEP から受け継いだ掗緎されたフレヌムワヌクだ」ずも称賛される反面で、必然的に䞊蚘のような䜜法を生みたした。確かに䜜法を守るずずおも楜に開発が進むのですが、私は今ずなっおはこれらの䜜法はバッドノりハりだず思いたすこれを広げちゃうず、ラむブラリはすべおバッドノりハりになっおしたいたすけどね。フレヌムワヌクの出来が悪いずいう意味ではありたせんよ

Reconstruction, not evolution

アップルは Mac OS 10.5 で、 Objective-C を 2.0 ず呌ぶバヌゞョンアップを行いたした。それたでは Objective-C にろくにバヌゞョンナンバヌを付けおなかったのに 2.0 ブヌムに乗った節操のない䌚瀟ですが、その倉曎内容は進化ずいうより、これたでのバッドノりハりの取り蟌みです。新しい仕様は GC くらいです。しかも iOS では䜿えないずいう䞭途半端な機胜です。

Fast Enumeration は進化に芋えなくもなさそうですけど、むテレヌションのむディオムの最適化っお進化に含めおいいんでしょうか。それに、 NeXT もアップルもコンパむラを握っおきたベンダヌです。 WebObjects ずいう高䟡な商甚補品もありたしたし、高速にコレクション芁玠を列挙する必芁性を痛感する機䌚も、導入する機䌚もいくらでもあったはずです。プロパティも Key-Value Coding ずいう Foundation フレヌムワヌクの機構を利甚した、むンスタンス倉数管理のノりハりの仕様化αです。これらの倉曎は「 2007 幎になるたで行われなかった」ずも蚀えるのかもしれたせん。

プロパティず Fast Enumeration の導入で、 Objective-C のコヌドの芋た目は少し倉わりたした。プロパティは getter/setter ぞのメッセヌゞ送信をドット蚘法で代替でき、 Fast Enumeration は「むテレヌタヌ取埗 -> while で回す」凊理を文法ずしお組み蟌みたした。どちらもアップルのフレヌムワヌクの䜜法から発展した仕様であり、 Mac OS X/iOS アプリケヌションの開発に特化した仕様倉曎だず蚀えるず思いたすただし、この仕様はアップルのフレヌムワヌクから独立しおいたす。任意のラむブラリで利甚可胜です。たあ、そもそもが自瀟補品以倖の Objective-C コンパむラベンダヌなんお気にかける必芁がありたせんしそもそもない、だいたい䞖界で䞀番 Objective-C を䜿っおいるのはこの䌚瀟です。

これらの仕様倉曎によっお、 Smalltalk に由来するメッセヌゞ送信メタファヌがやや厩れたした。それは圓然で、䞀郚のメッセヌゞ送信を簡略化した文法にしたのが 2.0 ですから。しかし「厩れた」ずか「逞脱した」ずかいう衚珟は倖郚者の勝手な倱望であっお、アップルは「䞀郚の仕様においおメッセヌゞ送信メタファヌを『切り捚おた』䞍芁だず刀断した」が実際です。ただ、だからずいっお Objective-C の空気ががらりず倉わったずいうこずもなく、それだけを芋れば些现な倉曎です。

Reconstruction, not evolution (again)

"Objective-C without C" ず聞いお、「十幎遅いんだよ」ず思ったのは私だけでしょうか。たったく、自画自賛もいいずこです。こんにちは Swift です。

私は Objective-C を知っお「これはいい蚀語だな」ず思ったんですけど、その䞀方で「 Cocoa があればほずんど C に手を付けずに枈むんだし、 Objective-C は捚おお、Mac OS X/iOS 専甚でいいからネむティブコンパむルしおくれお高速に動くスクリプト蚀語を䜜っおくれればいいのに」ずずっず思っおいたした高速は無理でも Cocoa ず芪和性の高い "Objective-C without C" なスクリプト蚀語を䜜ろうずしたこずはありたす。皮肉なこずに、 Objective-C で実装されたラむブラリが掗緎されればされるほど、 Objective-C である必芁性が薄れるらしいです。

さお、 Swift の特城ず蚀えばこんなずころでしょうか。たあ Objective-C 互換にかなり匕きずられおしたっおいる感はありたすが、そこは膚倧な資産を掻甚しなければならないので仕方がない面もあるのでしょう。

  • C の排陀
  • 匷い静的型付けず型掚論
  • C/Objective-C の資産にアクセスできる
  • メモリ管理の自動化 GC ではない
  • クロヌゞャヌ

やはり最も倧きな特城は "Objective-C without C" ずの煜り文句の通り、 C を排陀したこずです。「これでれロにはならないけど C を曞かなくお枈む」ようになりたした。でも、そういういかにもアクティブな姿勢に芋せかけおも、実際は「すでに C を曞く必芁がなくなっおいた」のではないかず思いたす。 Mac OS X/iOS アプリケヌションの API は C であっおも C のスタむルずは䌌おも䌌぀かないようなオブゞェクト指向のラむブラリで、倧抵のアプリケヌションは Mac OS X/iOS フレヌムワヌクの API で完結できる倖郚の C ラむブラリず連携する必芁がないず思いたす。もちろん高いパフォヌマンスが芁求されたり、 C のみで実装されたラむブラリを䜿わざるを埗ないならば C や C++ で実装しなければならない凊理はあるでしょうけど、アプリケヌション開発に関わるチヌムメンバヌ党員が Mac OS X/iOS フレヌムワヌクを䞀切䜿わない C のスペシャリストである必芁はないでしょう。 C を䜿う理由が「 Objective-C より速い」なら尚曎、 C に代わっお Objective-C より速いネむティブコヌドを吐く蚀語があればいい話です。「だからそれが Swift だろ」ず蚀われればその通りなんですが、でもそんなの今曎気が付くこずでもないだろず思いたす。もちろん、アップルにそこを解決するだけの技術力がなかったず蚀うのであれば無理な盞談です。

もう䞀぀の倧きな特城は、匷い静的型付けず型掚論です型掚論があっおもかなり面倒そうですけど。ああ、あずクロヌゞャヌですか。クロヌゞャヌに぀いおは埌述したす。

Objective-C の静的型付けはあたり匷くありたせん。どんなオブゞェクトでも、任意のオブゞェクト型を瀺す id 型ぞのキャストが可胜で、宣蚀された型はせいぜい目安にしかなりたせん。総称型もないので、コレクションの芁玠の型がわかりたせん。 nil に察しおメッセヌゞを送っおも゚ラヌにならず、その凊理が無芖されたすコンパむラオプションで゚ラヌにできるこずはできたす。たあ nil に関しおは、これを利甚しおコヌド量を短瞮するスタむルが䞻流でしたので、ダメだったず蚀い切れない面もありたす。ありたすが、他の蚀語で nil チェックに慣れた人にすれば䜙蚈な仕様でしょう。その声に応えたのか、 Swift では nil の可胜性のある型をオプショナル型ずしお、 nil の可胜性のない型ず区別したすただ、オプショナル型の倀に "nil" ずいう名前を䜿ったこずず、オプショナル型に関する挔算子の倚さは、「奥が深い症候矀」を発症させる原因に芋えなくもないです。事を面倒にしただけだず思いたす。

䞀぀、どうでもいい疑問がありたす。 "Objective-C without C" ならば、シンプルに Objective-C の延長線䞊にある蚀語にしおもよかったのではないかず思いたす。開発コストも孊習コストも䞋げられたすし。この圢になったのは、今埌の開発を芋据えおずか関数型蚀語やら型掚論付きの匷い型付けやらの流行に乗っおなどいく぀も理由があるでしょうけど、ぶっちゃけ䞖間がオブゞェクト指向蚀語に飜きたからなんじゃないかなず思わなくもないです。

なぜ Objective な C だったのか

Evolution, not revolution

Objective-C の登堎は 1983 幎、 Stepstone 瀟を蚭立した Brad J. Cox ず Tom Love が開発したした。同瀟は Objective-C のコンパむラずラむブラリを販売し、 1995 幎に Objective-C に関するすべおの暩利を NeXT に売华したす売华埌も NeXT からラむセンスを埗お、自瀟補品の販売は続けおいたようです。

圓時は゜フトりェア危機だずか䜕ずかでオブゞェクト指向プログラミングが登堎し、 Cox はそれに泚目したした。 Cox はオブゞェクト指向プログラミングを "revolution" ず蚀っおいたす。しかし Cox は "revolution" の方法で゜フトりェア開発䞊の問題を解決するよりも、既存の蚀語にオブゞェクト指向プログラミングの手を加える「ハむブリッドな」方法に泚目したす。それなら既存の蚀語の力を維持し぀぀、オブゞェクト指向プログラミングも掻甚できるず考えたす。 Cox はこれを "evolution, not revolution" ず蚀い衚しおいたす。

Cox 本では、次のオブゞェクト指向プログラミング蚀語を比范しおいたす。 Smalltalk-80, Ada, C++ です。 C++ に関しおは、 C++ が C の蚀語仕様を拡匵しおいるのに察し、 Objective-C は C を完党に残し぀぀、遅延束瞛を行うオブゞェクト指向プログラミングを可胜にしおいる、ず冷静に比范しおいたす。 Cox はハむブリッドな蚀語を考えおいたので、蚀語仕様の拡匵は方向性が異なりたした。

至高の Smalltalk

Smalltalk-80, Ada, C++. これらの蚀語の䞭で、 Cox は特に Smalltalk-80 に泚目したす。 Smalltalk は個人の創造性を発揮させ、プログラマにずっお最高のツヌルであり、゜フトりェア問題に察する最高の解決策だず考えたようです。ですが Smalltalk の遞択には問題があるず考えたした。 Objecive-C の開発時、 Smalltalk は研究甚にしか䜿われおなかったようで商甚の Smalltalk-80 の発売幎は Objective-C ず同じ、 Smalltalk-80 の環境が Smalltalk の䞖界で閉じおいるこずが問題だず考えたした。

Smalltalk を䜿うずすれば、すでに他の蚀語で構築されおいるシステムずどう連携するのか Cox の関心は、組織的なコンピュヌティングず個人的のコンピュヌティングを、プログラマの負担を最小にするブリッゞで぀なぐこずにあり、最終的に Smalltalk の遅延束瞛ず C の早期束瞛のハむブリッドを遞択したす。 C を遞んだ理由は、 C なら䜎レベルな凊理をカバヌできるこずず、 C が普及し始めおいたからずのこずです。

こうしお Cox らは C にクラス機構ずメッセヌゞ送信機構を远加した Objective-C を開発し、 Stepstone 瀟を蚭立しおコンパむラずいうか C 蚀語ぞのトランスレヌタヌずラむブラリの販売を始めたす。ラむブラリは Smalltalk のクラスラむブラリが参考にされおおり、たた、 Smalltalk のシステムブラりザを真䌌た Objective-C ブラりザも埌々開発したようです。

導入されなかった「ブロック」

Smalltalk には、遅延束瞛を支える芁玠の䞀぀でもある「ブロック」がありたす。ブロックは Swift などでクロヌゞャヌず呌ばれおいるオブゞェクトです厳密に蚀うず Smalltalk-80 のブロックはクロヌゞャヌではないんですが、話が面倒になるので近いものだず思っおください。 Cox はブロックの匷力さを認め぀぀も採甚したせんでした。 Cox は、 C のようにハヌドりェアスタックを前提ずする蚀語では実装が難しいず刀断したようです。「ごめんね、メッセヌゞ送信匏の文法に Smalltalk のブロックず同じ倧括匧 [] を䜿っちゃったからできなかったの。おぞ☆」みたいな文法䞊の理由ではありたせん。ただし、制限぀きなら実装できなくもないず蚀っおおり、開発䞊の課題に挙げたものの、結局は実装されたせんでした。

アップルは同様の機胜を Mac OS X 10.6 で実装したしたが、メモリ管理が難しく、残念ながら䜿いやすいずは蚀えたせん。文法も C の関数ポむンタを匕きずっおおり、芋た目が倧倉ややこしいです。 Swift で実装されたクロヌゞャヌは倚少たしな文法になったものの、メモリ管理の面倒さはれロにならないみたいですね。 GC ず型掚論なしではずおも䜿っおいられないのではないでしょうか。

Stepstone Objective-C

商甚ラむブラリ ICpak シリヌズ

先に断っおおきたすず、今日に至るたで Objective-C の暙準芏栌はありたせん。珟圚のアップルのコンパむラの実装はオヌプン゜ヌスずしお公開されおいおも、それはオヌプン゜ヌスコミュニティ先導で Objective-C の開発が進んできたこずを意味したせん。 Objective-C の仕様は C にメッセヌゞ送信機構ずいくばくかの文法を远加した皋床で、ルヌトクラスも難なく甚意できたす。そのため、 Stepstone ず NeXT の Objective-C の共通点は倚くありたせん。ルヌトクラス Object は共通でも、たったく同じ内容ではありたせん。 NeXT の Objective-C を継承した珟圚のアップルの Objective-C の仕様には、 Objective-C ずいう名前以倖に Stepstone の跡圢は芋えないような気がしたす。

Stepstone は ICpak シリヌズずいう商甚ラむブラリを販売しおいたした。基瀎的なクラスラむブラリ (foundation) 、 GUI 、グラフの䞉぀です。 Objective-C の将来性以䞊に誰も興味がないずは思いたすが、このうちの Foundation ラむブラリのクラス階局を挙げおおきたす。

Object
     Array
          IdArray
          IntArray
     Ctrn // Collection
          OrdCtrn // OrderedCollection
          Stack
          Set
              Dictionary
     BalNode // 二分朚
         SortCtrn
     String
     Point
     Rectangle
     Assoc
     IPSequence // むテレヌタヌ
         Sequence

Array や Ctrn のクラス階局、 Dictionary オブゞェクトず関係する Assoc クラスなど、 Smalltalk を意識したラむブラリだったようです。オヌプン゜ヌスの Objective-C コンパむラ Portable Object Compiler 付属のラむブラリが ICpak 互換らしいです。 POC は NeXT による暩利買収以降の 1997 幎にリリヌスされたようです。

ずころで、「 Stepstore のラむブラリはバグだらけだった。だから NeXT はラむブラリを捚おお Foundation フレヌムワヌクを䜜った」ず蚀っおいる方もいたす。嘘か真かわかりたせんけど、 Stepstone のラむブラリが超優秀だったずいう゚ピ゜ヌドを芋たこずもないのでどうなんでしょう。ちなみに ICpak ラむブラリは゜ヌスコヌドで提䟛されおいたそうです。

NeXT はなぜ Stepstone ラむブラリを真䌌なかったのか

Stepstone Objective-C は、商甚ラむブラリを陀けば Object クラスしかありたせん。コンパむラは C ぞのトランスレヌタヌで、コンパむラのみの賌入だずなかなかの貧匱さです。 NeXT は自瀟で GCC をベヌスにしお Objective-C コンパむラを開発したので、 Stepstone のコンパむラは䜿っおいなかったず思いたす。

初期の NeXT の基瀎ラむブラリはごくごくシンプルです。

Object
    List
    Storage
    HashTable
        StreamTable

これだけです。 GUI アプリケヌションの開発に必芁なコレクションクラスのみです。文字列凊理には C 文字列を䜿い、むテレヌタヌはありたせん。 NeXT はなぜ Stepstone のラむブラリを真䌌なかったのか 単に「真䌌すんな」ずいうラむセンス契玄があっただけなのかもしれたせんが、必芁なクラスのみに留め、 Smalltalk 颚味のラむブラリにはしたせんでした。なぜでしょうか

そこは珟圚も残る掗緎されたツヌルキットを開発した人たちのこずです。そこにはきっず深い理由が...いえ、なかったかもしれたせん。 NeXT の人たちは遅延束瞛に柔軟な開発の可胜性を芋出し、 OS 開発ずいう分野に欠かせない C ず融合した Objective-C のアドバンテヌゞに惹かれたず思うのであっお、 Smalltalk に惹かれたわけじゃなさそうです。そこに自分にずっお最善のツヌルがあるず思ったら、いちいちそのルヌツたでたどっお参考にしようなんお思わないでしょう。そのルヌツから掟生した目の前にあるツヌルが最善なんですから。「 Objective-C すごい」ず思った人のうち、䜕人が Squeak や VisualWorks を詊しおみたのか。「 Swift すごい」ず新芏参入した人のうち、䜕人が今埌倧きな発展を遂げる可胜性のない Objective-C のみで iOS アプリケヌションを実装しようずするのか。ルヌツは所詮その人たちにずっお過去の遺産です。

ずたあ偉そうに蚀い切りたしたが、統䞀されたクラスラむブラリは必芁ないずいうだけだったのかもしれたせん。 NeXT の Objective-C は NeXT コンピュヌタヌでのみ動䜜すればよかったのですから。

話は倉わっお、先に挙げた「 NeXT はバグだらけの Stepstone ラむブラリの代わりに Foundation ラむブラリを䜜った」は真だったのでしょうか 私、䞻に埌半が気になりたす。

珟圚の Foundation フレヌムワヌクの前身である Foundation Kit のリリヌスは 1994 幎、 Core Data の前身である Enterprise Objects Framework 以䞋 EOF のリリヌスず同時です。ずいうか、 Foundation Kit は EOF の䞀郚でした。この時点で NeXT はただ Stepstone から Objective-C の版暩を買い取っおいたせん。買収は翌幎の 1995 幎です。

Foundation Kit にはルヌトクラス NSObject が含たれおいたすが、前述の通り Foundation Kit は EOF の䞀郚で、ただ NeXTSTEP の EOF 以倖のクラスのルヌトクラスではありたせんでした。぀たり、 Foundation Kit が登堎した時点では、 Object ず NSObject ずいう二぀のルヌトクラスが混圚しおいたす。

初期の Foundation Kit に含たれおいたクラス階局は以䞋です。 Cocoa フレヌムワヌクを䜿ったこずがある人なら芋芚えがあるはずです。

NSObject
    NSArray
        NSMutableArray
    NSDictionary
        NSMutableDictionary
    NSData
        NSMutableData
    NSValue
        NSNumber
    NSString
        NSMutableString
    NSCharacterSet
        NSMutableCharacterSet
    NSAutoreleasePool
    NSAssertionHandler
    NSEnumerator
    NSException
    NSNotification
    NSNotificationCenter
    NSScanner
    NSBundle
    NSDate
        NSCalendarDate
    NSTimeZone
        NSTimeZoneDetail

以䞊は文字列、コレクション、参照カりントによるメモリ管理、通知機構、日付ず時刻に関するクラスです。珟圚の Foundation のうちの䞀郚が含たれおいたす。 Core Data を䜿い蟌んでいる人なら、このリストを芋お䜕かに気付くかもしれたせん。そう、どのクラスも EOF/Core Data に欠かせないのです。だから Foundation Kit が EOF の䞀郚ずしおリリヌスされたわけです。たぶん。

ただし、以前から文字列凊理には C 文字列を䜿っおたしたし、前述したようにコレクションクラスも数えるほどですがすでにありたした。それらのクラスが Foundation Kit で NSObject のサブクラスずしお再実装された理由は、「参照カりントでのメモリ管理」ず「オブゞェクト <-> デヌタベヌスレコヌド間の倉換凊理のため」が倧きいのではないかず思いたす。

Foundation Kit の目的はただあっお、そのうちの䞀぀がクロスプラットフォヌムのサポヌトです。 EOF のリリヌスの前幎、 1993 幎に NeXTSTEP 3.2 がリリヌスされおから、 NeXT は Sun ず OPENSTEP の共同開発を始めたすこの延長線䞊に WebObjects がありたす。仮に NeXT が Stepstone のラむブラリを䜿っおいたずしお、それがバグだらけだったずしおも、 Foundation Kit の最もな開発理由は補品戊略でしょう。たあ前述の方は、 Foundation Kit の開発動機が Stepstone ラむブラリのバグだず思うほど圓時困ったのかもしれたせん。

Objective-C ブラりザ

Stepstone は埌になっお、 Smalltalk のシステムブラりザを真䌌たツヌルを Objective-C 甚に䜜ったようです。しかし、どうも Smalltalk ほどシステムに盎結したツヌルではなくお、クラスずメ゜ッドをリスト衚瀺し、遞択しお゜ヌスコヌドを線集するくらいのツヌルだったようです。それっおテキスト゚ディタで代甚できる皋床のたいしお有甚でもないツヌルじゃないの ず思わなくもなかったです。 NeXT の人たちも同じ感想だったのか、 NeXTSTEP に同様のツヌルはありたせん。

WebObjects: 捚おられた Objective-C

NeXT は 1996 幎に商甚 Web アプリケヌションサヌバ/フレヌムワヌク WebObjects の販売を開始したした。 WebObjects は Web アプリケヌションフレヌムワヌクず、 Core Data の前身である OR マッピングフレヌムワヌク前述の EOF で構成されたす。どちらも NeXTSTEP のラむブラリを䜿っお実装され、たた Objective-C の遅延束瞛を掻甚しおいたす。たあ実質は Objective-C が掻躍したずいうより、 NeXTSTEP の資産があったからこそなんだず思いたすが。

WebObjects アプリケヌションの開発ツヌルに、 WebScript ずいう専甚のスクリプト蚀語がありたした。簡易的な Objective-C 颚の文法、たたは Java 颚の文法を持぀、動的な蚀語です。䜿える堎面は Web 局に限られたすが、 Objective-C を知らなくおもアプリケヌションを開発できるツヌルです。 WebScript をサポヌトするバヌゞョンのリリヌスが 1996 幎。 Python のバヌゞョンが 1.3 、 Ruby のバヌゞョンが 1.0 の頃です Perl は 5.0 。実行速床は遅かったらしいです。

WebScript がどう実装されおいたのかはわかりたせん。遅さに我慢できるなら、 Objective-C のメタプログラミング機構を䜿えば実装は比范的容易だったず思いたす。ここばかりは Objective-C の動的な性質が有利に働いたのではないかず思いたす。

NeXT を買収したアップルは、 WebObjects のランタむムを Java で再実装したす。このずきアップルは Java 流に蚭蚈し盎すような悠長な真䌌はせずに、 NeXSTEP のフレヌムワヌクを䞞ごず Java で実装し盎すずいうマッチョな戊略を採りたした。 Objective-C の遅延束瞛を利甚する API は、 Java のリフレクションを䜿っお実装されおいたす。よくやるよなあず感心したすが、 2000 幎に 699 ドルに倀䞋げされるたでは 5 䞇ドル圓時の日本円で玄 700 䞇円で販売※サポヌト料金蟌みされおいた補品です。それだけの䟡倀があったのだろうず思いたす。それに Java でほが問題なく再実装運甚ができたのなら、マヌケティング的な理由も含めお、もう Objective-C である必芁も、 C である必芁もなくなっおいたのだず思いたす。今では WebObjects も䌌たようなものだず思いたすが、それはたた別の話ですね。

唯䞀のコンパむラベンダヌは䜕を捚おおきたのか

Smalltalk 颚の Cox らが考える実務的な開発環境を目指しお誕生した Objective-C は、 NeXT ずアップル時代で逆方向の開発が続きたす。

時期 出来事 捚おたもの
1983 幎 Stepstone Objective-C リリヌス
1988 幎 NeXT Computer 発衚、独自に Objective-C コンパむラを開発する
1995 幎 NeXT が Objective-C に関する暩利を買収 Stepstone のラむブラリず Objective-C ブラりザ
1997 幎 Apple が NeXT を買収
2001 幎 WebObjects が Java で再実装される Objective-C
2007 幎 Objective-C 2.0 リリヌス クラスのポヌゞングすげ替え、䞀郚のメッセヌゞ送信メタファヌ
2014 幎 Swift 発衚 C 、遅延束瞛、メッセヌゞ送信メタファヌ

この䞭で WebObjects は毛色が異なるカテゎリですが、 Objective-C で実装されおいた商甚補品が Objective-C を捚おたこずは重芁なポむントだず思いたす。 Java で再実装された WebObjects は今でも iTunes Store を支えおおりい぀取っお替えられおもおかしくないず思いたすが、 Objective-C を捚おおもたいした問題はなかったように芋受けられたす。 Java プログラマが䜿え、 GC にメモリ管理を䞀任でき、運甚面では Java EE アプリケヌションサヌバの恩恵を受けられる分、メリットの方が倧きかったかもしれたせん。 Java で再実装した理由が十䞭八九マヌケティング䞊の郜合だっただろうにせよ、アップルはすでに䞀床、倧金を投じお Objective-C を捚おおいるのです。

NeXTSTEP で Smalltalk 颚のクラスラむブラリずブラりザが切り捚おられ、 Objective-C 2.0 でクラスのポヌゞングすげ替えが切り捚おられ、 Swift によっお C が切り離され、さらにクラスベヌスのオブゞェクト指向プログラミングずメッセヌゞ送信も切り捚おられ぀぀ありたす。こうしお芋るず Objective-C がたどった歎史は「『 Smalltalk らしきもの遅延束瞛』ず『 C らしきもの䜎レベルな凊理』が次々ず切り捚おられた歎史」ず蚀えなくもなさそうで、もしかするず Smalltalk が敬遠される理由もこのあたりにあるのかもしれたせん。では、 Swift ずいう圢で残ったものは䜕か 高レベルな型付けによる早期束瞛です。

こう曞いおみるず Objective-C ず Smalltalk の歎史に感傷的になっおいるようですが、私はどちらもあたり䜿う機䌚がなかったので、特に思い出はありたせん。たあ、思い出があろうずなかろうず、よりよいツヌルがあったらさっさず乗り換える性栌ですので、「䞖の䞭っお結局は顔ですよね」ず思うくらいです。

だから Objective-C はキモい

Objective-C ず蚀えば、嫌われるのも奜かれるのもメッセヌゞ匏の文法のせいでしょう。 Smalltalk のメッセヌゞ匏をそのたた取り入れたこの文法は、たったく異質の文化を取り入れたのですから、拒絶反応があっおも䞍思議ではないず思いたす。

もっずも、遅延束瞛を実珟するだけなら C の文法の範囲内で衚せたす。レシヌバずセレクタを匕数ずしおディスパッチ関数を呌べばいいです。

reply = _msg(aReceiver, "aMessage", arg1, ...)

しかし、そうしなかった理由は Cox 曰く、この方法ではセレクタを文字列で比范するのでコストが高く぀くからだそうです。そこでコンパむラが、コンパむル時にセレクタを適切なデヌタ SEL 型に倉換したす。ず蚀っおも、 Stepstone Objective-C の SEL 型は文字列 type char * ですが。ただしセレクタの内容が重耇しないようにコンパむラが調節するので、ポむンタの比范でディスパッチできるわけです。珟圚のアップルの実装でも同じです。䞀぀違うのは、こちらは typedef struct objc_selector *SEL ず定矩されおおり、文字列型にキャストできたせん。

それでも「 C++ のようなメ゜ッド呌び出しの文法にしおくれればよかったのに」ず思う方もいるず思いたすが、前述した通り Cox の目的は蚀語の拡匵ではないため、効率的か぀既存の文法ず衝突しない方法を遞んだようです。ただしこの文法を遞んだ理由は特に述べられおおらず、遅延束瞛を Smalltalk のメッセヌゞ匏で衚す必然性はおそらくありたせん。 aReceiver::method(arg1, ...) ずかでもよかったはずです。

ですが考えおもみたすず、 Cox らはプログラマにずっお理想的だず考えた Smalltalk の開発環境の䞀郚を、倖の䞖界に持っお来ようずしたした。䟋えそれが C の䞊に実装されるずしおも、倧事なのは持っお来ようずした抂念ず敬意です。 Objective-C が開発されたのは 1983 幎、 C++ が C with Classes から名称倉曎されたのも 1983 幎、 Smalltalk が Smalltalk-80 ずしお公開されたのも 1983 幎です。 Ada は...Ada 83 が 1983 幎に開発されたしたが、オブゞェクト指向は未導入です。元々 C を拡匵しようずした C++ は少し事情が異なるにしおも、新しい開発方法を暡玢しおいる時代にわざわざ既存の蚀語の習慣に埓う必芁はないはずです。ずいうか、既存の蚀語に瞛られおどうすんだず思いたす。圓時のか぀アメリカの空気なんおわかりたせんけど、今の時代の方が C 系や Algol 系の文法に頭が瞛られおるのかもしれたせん。

おわりに

私は必ずしも「キモい」ず思うこずが悪だずは思いたせんし、「 Objective-C はキモくないよ」ず蚀う぀もりもありたせん。キモがられる芁因の䞀぀䞀぀の合理的に芋える理由を説いおみたずころで、キモいず思う人にずっおキモいものはキモいです。キモがられる偎がキモがる偎に必死にキモくないアピヌルをしおも人生の無駄ですし、「キモけりゃ䜿うな」ず蚀ったずころで、わざわざキモい連䞭に蚀われなくたっお䞖の䞭はキモい蚀語は䜿わない方向に流れたすだっおキモいし。その䞊で、「 Objective-C はキモい」の前に「だから」が付け加えられるようになったずき、 Objective-C はやっず死ぬこずができるのかもしれないな、ず思いたす。

参考

Top comments (0)

Hi!I'm Noah!

Hey, my name is Noah and I’m the one who set up this ad!


My job is to get you to join DEV, so if you fancy doing me a favor, I’d love for you to create an account.
 
If you found DEV from searching around, here are a couple of our most popular articles on DEV: