並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる～
async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専
実行時にCompiledNameが付いた型の元の名前を取得する - 2つのアンコール
正確には実行時じゃないけど解決したのでメモ 元ネタ: http://ja.stackoverflow.com/questions/6177/compilednameが付いた型のf-での名前を取得したい 問題 F#では、CompiledNameAttributeを付けた型は、リフレクションで元の名前を取得できません。 [<CompiledName("Piyo")>] type Hoge() = class end というクラスを定義し、リフレクションで型名を取得しようとすると、 > typeof<Hoge>.Name;; val it : string = "Piyo" "Piyo"という文字列が返ります。 ソースコード上では"Hoge"という名前でしかアクセスできないのに、取得できないのは何かと不便ですね？ コンパイル前の名前が格納されている場所 アセンブリに、リソースとしてFSharpS
テストのためだけに`interface`を書きたくないでござる — KaoriYa
golangでテストのためだけにinterfaceを書くのが死ぬほど嫌だったので編み出した技を紹介します。 TL;DR テスト(=mock)のためだけにinterfaceは切りたくない 型エイリアスとビルドタグを組み合わせるとinterfaceがなくてもモックが作れる この手法に必要なモックを自動生成するプログラムを作った interfaceは本当に必要なシーンで使うべき Background 現在モックを使った単体テストは一般的です。 Javaでの例を挙げると、モックしたいコンポーネントについて予めinterfaceを定義しておき、モックではそのインターフェースを実装するのが定石です。 しかしgolangのinterfaceはJavaなどのそれとは若干性質が異なるため、テスト=モックのためだけにinterfaceを書くのはオーバーワーク気味です。 そうテストのためだけにinterface
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Alice(@cannorin)のまとめ(6)
