swift de classDriven その1 virtual関数と具象実装

どんなにFPを極めようと、結局中でやってることはblocksなので、FP恩恵の一部しか受けられない、FPの何が嬉しいかが解ってればまずObjC + blocksで書き下せる、Cocoaが結局ObjC目線なので、エンジニアは何かしらCocoa + ObjCとのコンパチで軋轢を被る、おかげでかっこつけて実装した参照透過性すらだいなし。なにやってんだか。

とはいえApple様はもうアランケイってだれ？状態で、罪をNextとObjCなんならPARCにもかぶせて捨て去りたくて仕方ない、そして最も厄介なことにswiftは教育含め、特にwanabe相手に金になる。

 

そんな、言語仕様界のあばれはっちゃく、swiftに時間を見つけて着手していこうかと。

ObjCのときは、OOPなら当然実装されているべき仕様が、変な小技使わないとできなかったり、結構はまりポイントだったので、その辺から。

 

いやはや、FPを知ってればOOPの代わりになると勘違いしてる輩が多いけど、ScalaやらOcamlやら、今OOPとFP組み合わせのパラダイムシフト中だから。

OOP極めてないと、いくらFP学んでも何の恩恵も得られないよ？というメッセージをこめつつ、とりあえず、初回はFBで先行で出した記事2件のコピペ

 

2016/4/16 晴れ

swiftで継承構造とabstractメソッド的なことやってみた。

例えばクソほどボタンが必要なときに、実装さえあるなしに応じて1メソッドで分岐する。

あれば、具象実装末端まで落ちていく

なければ、default実装へ。

default実装が存在するので、厳密にはstroustrupのvirtualなんだけど。

CallerClassでassert(sender.action())かかるよう、UITestで全叩きさせるとリリースストッパにできていいかも。
なお、Javaがなぜファイルで明確にひとつずつの処理単位(actor)を分けられるようになっていて、それの何が嬉しいとして言語設計されているのかよくわかんない人にはお勧めしない。

多段継承したとき、ObjCみたいにKVSで自前管理しなくていいぶん素直かな？
結局実体はKVS管理なんだとは思うけど。。。

 

 

 

2016/4/17 曇り

swiftで...その２
多少ググってswift流ならどうやるか調べてみた版。
こっちの方が、abstっぽくはなったが。。。
ちがいは、まだ構築中で未実装関数にPCが当たったときに、@noreturn関数内で完全停止するか、何らかdefault処理が入るか。
言うなれば、その１はvirtual(C++)、その2がabstract(Java a.k.a C++ pure virtual)といったところ。

好みと言うだけだけど、出荷後にやっちまったことが発覚したときのFS性から考えるとvirtualの方だろうなぁ。

 

Releaseで関数ごと入れ換えればいいだけなので、リリース、テスト、デバッグの各コードを疎に保てる。

 

テスト中に失敗検出のため、わざと落とすのと、デリバリ後にユーザの手元で落っこちるのとでは目的が全然違うからなぁ。

僕のインチキ設計哲学では、目的に合わせて極小影響粒度でオブジェクトやら処理やらを入れ換えるというのが好み。

abstは実装段階で忘れず全部梱包しろよってことだと解釈してるので。

 

個人的には、virtualでもabstractでもあまり興味は無く、言語設計つまりOSとの親和性として、どちらがCocoa設計に即しているかだけなんだけど。

 

swift blogみてもそういう所は出てこないんだよな。