Skip to content

Instantly share code, notes, and snippets.

@eed3si9n
Created July 16, 2013 02:05
Show Gist options
  • Star 1 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save eed3si9n/6005226 to your computer and use it in GitHub Desktop.
Save eed3si9n/6005226 to your computer and use it in GitHub Desktop.
Black Lagoon 翻訳のノート 翻訳: "Cake Pattern: The Bakery from the Black Lagoon" http://okapies.hateblo.jp/entry/2013/07/15/232456
現行訳: save関数はUserModuleにもMessageModuleにもあるので衝突してしまう。ここでは引数の型が違うのでコンパイラエラーになるけど、オーバーロードの場合は C++ の悪夢の日々よ再び。
訳案: save関数はUserModuleにもMessageModuleにもある。受け取る型が違うので、コンパイラはこれを区別することができるけど、それはオーバーロードだ。オーバーロードはキモいし、酷いし、C++ 時代の遺物なので、できれば回避したい。
現行訳: 巨大なシステムでモックを使いたいときは、Spring 等の依存性注入フレームワークを使うだろう
訳案: Spring 等の依存性注入フレームワークを使って大規模なシステムでモックを使ったことがある人は、それがいかに大変かを知っているだろう。
現行訳: 問題は、複数のモジュールに起動ルーチンと停止ルーチンがある場合だ。モジュールから他のモジュールへ委譲するのは、非常に複雑になるのでやりたくない。
訳案: 問題は、起動・停止ルーチンがあるモジュールが複数ある場合だ。ルーチン内から各モジュールが自分以外のモジュールに次々と委譲していくのは、非常に複雑になるのでやりたくない。
現行訳: 少し注意が必要なのは、これらのライフサイクル関数の正確な実行順序は、自分で順番を取り扱うべきだということだ。
訳案: 少し注意が必要なのは、これらのライフサイクル関数の正確な実行順序は非決定的ではないが、非決定的だと思って扱うべきだということだ。
現行訳: 問題は、僕らが JVM に立脚しており、またvalが先行的 (eager) に構築されないことだ。
訳案: 問題は、僕らが JVM に立脚しており、またvalが正格な (eager) 構文であることだ。そのため、Scala は実行パス中でトレイトのコンストラクタ内のval 構文へ到達するとそれを即時に実行する。他のあらゆるものの状態や、そのvalが何を使うか否かや、そのvalが使うものが利用可能であるか否かはお構いなしだ。
現行訳: 同様の問題は Java でも見られるもので、長命なスレッドのスタックオーバーフローの原因となる。
訳案: 同様の問題は Java でも見られるもので、StackOverflow へ行くと一年中誰かがこれに関するスレを立てている。
(インデントする必要無し)
現行訳: コンストラクタは基本的に、クラスが実行中であると予測する。そして、Cのコンストラクタは真っ先にAのコンストラクタへ委譲する。
訳案: クラスC の初期化の過程を見ていこう。まずコンストラクタが実行される。Cのコンストラクタが真っ先に行うのは Aのコンストラクタへ委譲することだ。
現行訳: 先行評価 (eager evaluation) は副作用のもう一つの形態だ。
訳案: 正格評価 (eager evaluation) は副作用のもう一つの形態だ。
現行訳: これは、プレゼンテーションコンパイラが大きな原因だ。プレゼンテーションコンパイラそのものは Cake Pattern と直接に連携することはないが、Cake Pattern が型エイリアスを壊すからだ。プレゼンテーションコンパイラはそんなに幸せではない。全く奇妙な型エイリアスと連携する必要がある場合もある。
訳案: 特にプレゼンテーションコンパイラが酷い。プレゼンテーションコンパイラは Cake Pattern を正しく処理できないため、ENSIME を使うのは諦めたほうがいい。Cake Pattern によって型エラーが滅茶苦茶になる。
(これが Not-presentation compiler の項なので別点にするべき)
現行訳: プレゼンテーションコンパイラはそんなに幸せではない。全く奇妙な型エイリアスと連携する必要がある場合もある。
訳案: プレゼンテーションではない (つまり普通の) コンパイラも機嫌が悪くなることがある。全く意味不明な型エラーを見たことが何度もあるが、仕方がないので我慢するしかない。
現行訳: sbt でも同じ問題がある。最近のバージョンではもう解決していると思うが、sbt 0.11 では、インクリメンタルコンパイラが必要ないものを再コンパイルすることで、変更を発生させることがある。あるいは、クラスファイルを???のままにしてしまうことでプログラムの意味論に誤りが起き、それらをケーキにすると???になることがある。
訳案: sbt にも別の問題がある。最近のバージョンではもう解決していると思うが、sbt 0.11 では、本来再コンパイル必要ないはずのものをインクリメンタルに再コンパイルしてしまうことで必要無いものが変更されたり、最悪古いクラスファイルが置き去りになってしまうことがある。これが Cake に含まれていると壊れずに、間違った意味論を持ったプログラムができあがってしまう。
(ここは前項の続きなので、別点にする必要無し。???は "stale" です)
現行訳: どちらがベストだろうか。君がプログラムを実行すると誤った答えが出て、原因を解明すると単にクラスファイルが???であることが分かる。
訳案: 君がプログラムを実行すると誤った答えが出てくるなんて最高じゃないか。原因を解明すると単にクラスファイルが古いだけだったことが分かる。本当意味不明。
現行訳: Scaladoc
訳案: Scaladoc も Cake Pattern をうまく処理できないので、API ドキュメントが好きな人は注意。
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment