Kyoto.go remote #7 Re:プログラミング言語Go完全入門 お題
気になったこと/わからなかったこと/疑問に思ったこと
エラー処理を適切に扱うのは難しいと思うのですがどういった点に注意して実装したり、レビューされていますか?なにをもってエラー処理の目的を達成していると言えるのかの指標や参考になりそうなアイディアなどがあれば知りたいです。luccafort.icon
この辺参考になります by tenntenn
受け取り手によって伝え方を変える -> p.12
wrapしなくても困らないときはwrapしなくてもいい
wrapするのは手っ取り早いが、wrapされまくりのログが表示されたときにうれしいか?
ウェブ開発だと「運用者がログを読む」というケースが多いので、原因調査しやすくするとか
バケツリレーつらい?
Goではエラーを明示的に処理するというポリシーなので、バケツリレーになるのは言語の設計意図通り
去年あたりに解決策が提案されていたが、討議の結果「いらないのでは」という結論になった
structやinterfaceの埋め込みはどういうユースケースがあるのか気になります(uji)
テストで使うモックオブジェクトで↑を使ったりする
他に使用例があれば知りたい
インターフェースの合成: 追加でエラーメッセージを乗せたり共通化したいところだけを定義できるので便利
varと:=の使い分けを雰囲気でやっている(空の値を定義したいときはvarを使う?)のですが、公式のドキュメントのどこかに使い分けガイドのような情報はあるのでしょうかyebis0942.icon
var使うときは型が明示的にしたいとき、 := は関数とかメソッドとかで値を受け取るとき…みたいな使い分けをしてます。理由は特にないがサンプルコードが多かったのでそれに従ってるluccafort.icon
varでも型推論されるよ!知らなかったよママンluccafort.icon
var使いたいときはゼロ値で使いたいとき by tenntenn
varと:=を用意しているのは何故???
おそらくショートハンド。
code:hoge.go
func SumAll(numbersToSum ...[]int) []int {
var sums []int
for _, numbers := range numbersToSum {
sums = append(sums, Sum(numbers))
}
return sums
}
関数と型 p.32の「削除」のサンプルはどちらでもパフォーマンスは変わらないんでしょうか。たぶん同じだけメモリコピーが実行されるのかなと思うのですが…yebis0942.icon
同じはず。でもメモリは確保されない。
appendのコードを読んでみるとよいかも。
並列処理と並行処理に違いについて質問したいです。 Go言語では、並行処理という名前がよく出てきますが、go routineを利用すると全て並行処理になるのでしょうか? go routineをシングルコアで利用 → 並行処理 マルチコア、複数のCPUで利用 → 並列処理 という認識を持っているのですが、どのような解釈が正しいのでしょうか? (tekondo)
go routineを利用すると全て並行処理なのか?ということについて知りたいです (tekondo
「ゴールーチンでConcurrencyを実現」が正しそう
テストケースの整理の仕方が気になっています。RubyのRSpecを長く使っていたので、ネストでテストケースのコンテキストを表現する & 1つのブロックで1つのアサーションというスタイルが体に馴染んでしまっていて、Goらしいテストコードがうまく書けなくて困っています。うまく矯正する方法はないでしょうか(たくさん書くしかない?)yebis0942.icon
code:hoge_spec.rb
# 例が微妙だったので修正しました
context '入力が3なら' do
expect(fizzbuzz(3)).to eq 'fizz'
end
1つのテスト関数の中で変数を再利用しながら何度もアサーションする
RSpec文化圏だともっと細分化したテストケースにしたくなりそう
最近のGoではロジックとテストケースは分離させるのが一般的 by tenntennさん
↑の例はちょっと古い時期のコードかも
なりますね。このあたりをいじっている人は強いので平気かもしれないけど、一般的には分けた方がいいと思います。
オブジェクト指向なのか?
Goでできること
カプセル化
Goでできないこと
継承
これってそもそもオブジェクト指向の性質なのかという議論はある
継承できてない例: 「6. 抽象化」のp.22
C++/Javaの気持ちで設計すると継承ができなくて痛い目を見ることがある
「埋め込みでいける気がしたら、それはだいたいダメ」 by tenntennさん
普通にフィールドにしてください
Goは一般的には「テクニック使える!」と思ったらまずい。愚直にやりましょう
「継承したくなったらフィールド」でほぼいけるはず
OOP界隈でも「継承しない」という派閥がある
ヤバい例: 「子が親を書き換える」
確認したいこと
次回やりたいこと