Go language part 1

Go language part 1at TECH

Go language part 1 - 暇つぶし2ch■コピペモード
□スレを通常表示
□オプションモード
□このｽﾚｯﾄﾞのURL
■項目テキスト

1001:デフォルトの名無しさん
 17/11/11 15:36:08.28 proXGFSN.net
>>985 
>動的言語の場合は既に言われているようにスキーマ管理が一元化出来る 
>（正確にはやらなくてもそのまま動くだけだが） 
> 分だけ書く量は少なくて済む。 
> プロトタイピングには動的言語の方が向いてる。 
同意する。Goでデータベース操作の決定版がでないのが物語ってる。 
逆にGAE/goのdatastoreを使うときはGoとの相性の良さを感じる。 
スキーマがGo側に設定することが決まっているから。

1002:あ
 17/11/11 15:56:16.25 X8lWnCzG.net
>>985 
まー、確かに。 
正直すぐ死ぬプログラムならメモリ管理もしない()という選択肢もあるわけだしな。 
外の世界と相性の悪い言語だと言うことは確か。 
形が適当なjsonとかとも同様にいちいちキャストがしちめんどくさいし。 
c#で言うdynamicみたいな型がありゃ良いなとは思うが、コンパイル時に解決してる事を善とするので無いのは仕方ない。向いてないわ。

1003:デフォルトの名無しさん
 17/11/11 16:18:54.52 LLMRc4SD.net
というか、これはAPIが足りてないんだね。 
（以下コードは文法があやふやなので参考程度で） 
database/sqlはScanを使うのが定番のようだが、Scanではargsの可変長指定しかないのがいけない。 
だから構造体の中身を確認するのにリフレクションが必要になってしまう。 
type Thread struct { 
no int 
time int 
body string 
} 
th := Thread{} 
rows, err := db.Query("SELECT * from threads;") 
err = rows.Scan(&th.no, &th.time, &th.body) // ここでばらすから中身を知らないといけない 
とりあえずScanが構造体を受け、その構造体にScannerインタフェースを実装する方式なら、 
リフレクションは回避出来るし、おそらく最高速度で動く。 
ただ、このためのAPIがない。 
err = rows.Scan(&th) // ばらさずに構造体を与える 
func (th Thread) Scan(src interface{}) err // 各構造体でばらす。手間は増えるが最速

次ページ