Go読書会 #13 がランサーズ株式会社で行われたので進捗と技術的なメモ書きを書いておきます。読書会の内容はプログラミング言語Goを冒頭から皆で読み進めていくというものです。
進捗した内容
- 7章 インタフェース
- 7.11 型アサーションによるエラーの区別
- 7.12 インターフェース型アサーションによる振る舞いの問い合わせ
- 7.13 型Switch
- 7.14 例：トークンに基づくXMLデコード
- 7.15 ちょっとした助言
- 8章 ゴルーチンとチャンネル
話題に上がった話
7.11 型アサーションによるエラーの区別
ここでは、最後の文言が話題になりました。
たとえば fmt.Errorfを呼び出して、エラーメッセージがもっと長い文字列に結合されると、 PathErrorの構造体は失われます。
この発言の意味が、ぱっと見わからず、エラーメッセージが長い文字列になりすぎた故に、PathErrorの構造体情報が視認しづらくなり、情報がそれをみる人間にとって失われるという意味なんじゃ無いかと思うんですが、発言が長い文字列と失われるがどうとらえて良いのか難しいです。
7.12 インターフェース型アサーションによる振る舞いの問い合わせ
ここでは、型アサーションを使用してインターフェースを満足しているかどうかを判定することにより、処理を分岐させる方法がio.WriteStringを例に取って説明されていました。
if _, ok := w.(WritString); ok {
....
}
あと、メソッドが満たす暗黙の想定が存在することも書かれていてそこも興味深かったです。
7.13 型Switch
ここでは、インターフェースの具象型の操作を隠蔽するメソッドを強調するスタイルと、インターフェースを様々な型の共用体と見なし具象型を強調するスタイルの2種類について言及されていて、型switchは後者の方です。
型アサーションによる分岐をswitch文で行う話がメインでした。switch文へ型アサーションを適用すると、データ型で分岐が出来て非常に分かりやすい書き方が出来ます。
swtich x.(type) {
case nil:
case int,uint:
case bool:
case string:
defaut:
}
7.15 ちょっとした助言
ここで興味深かったのは、設計の段階でインターフェースを作りすぎないことが大事でだということが書かれていた点です。抽象型であるインターフェースで設計をすすめて必要も無いのにインターフェースだらけになる設計をしてしまいがちですが、そんなことはする必要が無く2つ以上の具象型がある場合のみ必要に応じてつくれば言い問うことでした。
8章 ゴルーチンとチャンネル
ここでは、質問として並行プログラミングとjsの非同期処理と何が違うのですかというものが上がったので
こちらを挙げて議論等をしました。
この辺、並列と並行どうちがうのかとか、ブロッキング、ノンブロッキングI/O、I/O多重化、fork、threadなど話し始めると切りが無いのですが、
など参考文献を挙げながら話を進めました。
ここまで呼んだところで、時間になりました。次回は 8.1 ゴルーチンからです。