isomorphic所感
React・Fluxまわりをひと通り触ってみたので所感を徒然。
isomorphicなアプリを書く
そこまで大した話ではない。
- isomorphicなライブラリをnpmで入れる。
- isomorphicなコードを書く。
- node.js(io.js)ではそのまま動作。
- ブラウザ用にはbrowserify。
所感:
- bowerのオワコン感。
- webpackのtoo complicated感。
altJSの選択
巷のFluxライブラリはReact前提な部分があるので、全てを生JSを書くことはまず考えられない。
ほぼ以下の4択（ハイブリッド可能）。
- CoffeeScript
- 書きやすさ以外に特筆すべき部分はない。
- TypeScript
- 型を書けるという圧倒的ユニークスキル。
- JSX
- The React。ES6のサポート。
- ES6 JS (babel, etc.)
判断の軸:
- 型
- これを再重視するならTypeScript以外の選択肢はない。
- 書きやすさ
- CoffeeScriptはなんだかんだで書きやすい。ただES6が十分書きやすいので、今後の立場はどうなるか。
- 将来性
- 当然のことながらES6がランタイムの最適化の期待大。
- React親和性
- 1つのライブラリがコンパイラの選択肢にまで影響を及ぼすとは。
- あるいはVirtualDOMを簡単に書くためのライブラリを使うのは手だが…。
所感:
- 個人的には全てをbabelに統一するのが良い感じはしている。
- babel, babel-node
- browserify, babelify
- JSXサポート
- ES7サポート (stage 0)
- ただしJSDoc3はES7シンタックスをまだサポートしていない。
isomorphicを崩す仕組み
変な表現ではあるが、全てを共通コードにするのは無理。
- サーバー側: DB, セキュリティ, ...
- クライアント側: CSS, アニメーション, ...
透過的に委譲するような仕組み
- Fetchr的な
クライアント側にサーバー側のコードを見せたくない話
- JSファイルサイズ肥大化
- セキュリティ
目下この部分を考え中
- コンパイラレベルのサポート。conditional compilation的な。
- あまりこういう話はhotじゃない感。
- 今はエントリポイント分けて頑張るか。
Fluxについて
TODO
Polyfilについて
TODO
*1:元es6to5
フローチャートが書けない
昔、講義でフローチャートを書かされたような記憶はあるが、
全く自慢にならないが、今「フローチャート書いて」と言われても書ける自信が全くない。
開始が四角で分岐が菱型だったけ？線引いてYes/Noみたいな。そんな感じ？
とはいえ、ドキュメントでフローを表現したいことは間々あるわけで、じゃあどうしているの？
という問いに対しては「擬似コードで良くね？」と答えたい。
フローチャート - Wikipedia
この図もそうであるが、基本的にフローチャートは、擬似コードで書ける。
function sumFrom1To10() { var n = 1; var s = 0; while (n < 10) { s += n; n += 1; } return s; }
JavaScriptで書いてみたが、言語は何でも、それこそ架空の言語でも良いと思う。
書き方もあえてフローチャートに合わせてwhile使ってるが、for使えばもっとシンプルに書ける。
...
というようなことを考えていたら、フローチャートは過去の遺物的は議論は既に結論が出ている話題のようだ。
...
では、フローを表現する図は不要なのか、という言われると、そうでもない。
例えば、UMLのシーケンス図は、擬似コード化しづらいので重宝する。
もちろんシーケンス図も完璧ではないが、PlantUML使えばテキストで書けるし、不満は少ない。
オチは特に無い。
PHPの小ネタ: タイプヒンティングの罠
タイプヒンティングとは
PHP5からタイプヒンティングという似非タイプチェック機能が使えるようになっています。
<?php interface Runnable { public function run(); } class Foo implements Runnable { public function run() { echo 'Foo', "\n"; } } class Bar { public function run() { echo 'Bar', "\n"; } } function run(Runnable $runner) { $runner->run(); } run(new Foo); run(new Bar);
Foo PHP Catchable fatal error: Argument 1 passed to run() must implement interface Runnable, instance of Bar given
なるほど中々悪くなさそうな機能です。 が、このタイプヒンティングという機能には、色々と罠が潜んでいます。
スカラー型には使えない
ちゃんとマニュアルを読みましょうという話ですが、
タイプヒントは int や string といったスカラー型には使えません。 また、リソース や トレイト も使えません。
と書かれています。
<?php function add(int $a, int $b) // NG { return $a + $b; }
ついついやりたくなるんですけどね…。
nullは渡せない、が渡せないこともない
何言っているのかというと、こういうことです。
<?php function echoTimestamp(DateTime $dt) { echo ($dt ? $dt->getTimestamp() : 0), "\n"; } echoTimestamp(null);
PHP Catchable fatal error: Argument 1 passed to echoTimestamp() must be an instance of DateTime, null given,
なるほど、nullは渡せないのか！ と思いきや。
<?php function echoTimestamp(DateTime $dt = null) { echo ($dt ? $dt->getTimestamp() : 0), "\n"; } echoTimestamp(null);
0
デフォルト引数にnullを与えている場合は、null値を引数に渡せます。なんじゃそりゃ。
しかし、デフォルトのパラメータの値として NULL を使用した場合は、後から任意の値を引数に指定できるようになります。
デフォルト引数が無いときにnull値を与えられないというのは、メソッド内部でnullかどうかで分岐してないということが保証されるので、それはそれで良いのかな*1と良心的に解釈できますが、デフォルト引数nullの仕様は完全に蛇足な気がします。
<?php function addSeconds(DateTime $dt = null, $seconds = 0) { if (is_null($dt)) { $dt = new DateTime('now'); } return $dt->add(new DateInterval("PT{$seconds}S")); } $dt = new DateTime('now'); echo $dt->format('H:i:s'), "\n"; echo addSeconds($dt, 300)->format('H:i:s'), "\n"; echo addSeconds(null, 300)->format('H:i:s'), "\n";
全部にデフォルト引数与えるの、なんか違わない？引数なしで呼べるけど意図した使い方じゃないよね、という…。
所感
タイプヒンティングは、nullが来ないことを保証されているのだとポジティブに考えて、上手に使うのが良いのかと思います。
hacklangではもっと厳密に型を宣言できるようなので、一度試してみたい所です。
