Go language part 4

**デフォルトの名無しさん** · 2020/11/16(月) 04:14:40.64

Goについて扱うスレッドです。
GoはGoogleによって開発された言語です。

公式
https://golang.org

公式ドキュメント
https://golang.org/doc/

公式外パッケージドキュメント
https://godoc.org

ブラウザ上で試し書き
https://play.golang.org

※前スレ
Go language part 3
https://mevius.5ch.net/test/read.cgi/tech/1571315884/

**デフォルトの名無しさん** · 2021/01/21(木) 05:17:47.11

イクヤさんを馬鹿にしてんのか？

**デフォルトの名無しさん** · 2021/01/21(木) 07:41:51.93

>>317
バカにされているのはお前自信だぞw

**デフォルトの名無しさん** · 2021/01/21(木) 10:36:56.38

>>301
これ教えてくれや

**デフォルトの名無しさん** · 2021/01/22(金) 23:26:34.48

goのパッケージで、全然違う役割で同じパッケージ名つけなくなったときみんなどうしてる？

**デフォルトの名無しさん** · 2021/01/22(金) 23:47:27.87

apiwrapper2
apiwrapper3
saigo_no_apiwrapper
apiwrapper_final
こんなかんじで

**デフォルトの名無しさん** · 2021/01/24(日) 02:37:19.18

>>321
そうかぁ...なんだかなぁ

**デフォルトの名無しさん** · 2021/01/24(日) 04:02:02.83

イクヤさんはバカじゃないぞ。
ただの嫌な奴だ。

**デフォルトの名無しさん** · 2021/01/24(日) 19:31:46.17

import (
zenzen "xxx.com/omae/package"
chigau "xxx.com/aitsu/package"
)

**デフォルトの名無しさん** · 2021/01/24(日) 22:40:05.67

>>324
いや、自分が作ってるアプリ内でパッケージが被りそうな場合ですー

**デフォルトの名無しさん** · 2021/01/24(日) 23:29:36.37

>>325
自分でも同じじゃないか？

**デフォルトの名無しさん** · 2021/01/25(月) 18:17:56.09

>>326
たとえば、

package encrypt

っていう、APIの通信を暗号化するパッケージを自分で作ったとして、あとからユーザーがアップロードした画像を暗号化する処理作りたくなったとき、また

package encrypt

ってつけたくなるけど、最初に作ったAPIを暗号化する処理向けにすでに「encrypt」って使われてるからどうしよーってなるって話ですね

package apiencrypt
package userimageencrypt

にするのが普通ですか？

**デフォルトの名無しさん** · 2021/01/25(月) 18:55:36.51

>>327
いや、同時に使用する場合でも>>324さんの言うようにエイリアスで区別してインポートして使えばいい
例えば標準パッケージのnet/httpに対して、サブリポジトリにもgolang.org/x/net/httpがあったりとか、実験的実装でも同じパッケージ名をつけたりしているし

**デフォルトの名無しさん** · 2021/01/25(月) 19:17:10.86

>>328
いや、importするときの話ではなくて、実装する時の話です！
ちょっとあとでサンプルコード用意しますね！！

**デフォルトの名無しさん** · 2021/01/25(月) 20:10:27.92

>>329
だから公式でもやってるから気にするなw

**デフォルトの名無しさん** · 2021/01/25(月) 21:54:18.14

何がそんなに嫌なんだ？

**デフォルトの名無しさん** · 2021/01/25(月) 22:12:50.28

単にエイリアスのことを理解してないだけでは？

**デフォルトの名無しさん** · 2021/01/25(月) 23:54:29.57

すいません、僕のエイリアスの理解が間違ってました。↑でみなさんが言ってることが正しいです。
意味不明な事言って、誠に申し訳ありませんでした😳

**デフォルトの名無しさん** · 2021/01/26(火) 00:02:10.18

このスレでgolangのモヤモヤが一つ解消できました。本当にありがとうございました。

**デフォルトの名無しさん** · 2021/01/26(火) 01:18:09.44

別にgolangだけじゃなく他の言語もほぼ同じ仕様だぞ

**デフォルトの名無しさん** · 2021/01/26(火) 02:03:46.73

意外と素直なやつで気にいった

**デフォルトの名無しさん** · 2021/01/26(火) 15:48:34.40

>>335
別ディレクトリの同一パッケージ名つけちゃうと、同じパッケージという扱いになると勘違いしてました。
ディレクトリが違えば、ちゃんと別パッケージ扱いになるんですね

**デフォルトの名無しさん** · 2021/01/26(火) 19:32:50.53

公開したアプリの機能追加しようとしたらgolintがまたゴネはじめた
調べるともうdeprecatedが可決されてるんだな
Apiと書くとAPIにしなきゃ絶許とかアホな子なんで困る

**デフォルトの名無しさん** · 2021/01/26(火) 19:41:08.73

すなおにgolangci-lintに切り替えた

**デフォルトの名無しさん** · 2021/01/27(水) 15:46:00.33

最近素直な人多いね🤗

**デフォルトの名無しさん** · 2021/01/27(水) 19:26:08.32

素直に尿道オナニーした

**デフォルトの名無しさん** · 2021/01/27(水) 20:43:24.94

>>341
素直やなあ

**デフォルトの名無しさん** · 2021/01/30(土) 20:27:47.43

ごー言語ってどんなメリットがあるの？

**デフォルトの名無しさん** · 2021/01/30(土) 20:40:40.31

高速なWebAPIが超楽に作れる

あとは、慣れるとスクリプト代わりに使える

**デフォルトの名無しさん** · 2021/01/31(日) 00:23:18.15

実行環境側で準備がいらないから、ちょっとしたツールとか作って人に配ったり、サーバーで実行したりしやすい

**デフォルトの名無しさん** · 2021/01/31(日) 02:08:30.36

linuxとwindowsで動かすツールにjava使ってたんだけど
少しづつGoに移植してる
かなり良い感触
ついにjavaを捨てられる

**デフォルトの名無しさん** · 2021/01/31(日) 02:54:28.37

>>345
それがあったか！

あとgithubからcloneしてこなくても go run できるのは意外と便利

でもこないだ statik を run したらノートンが怒って temp に作成された statik のイメージを問答無用で削除
build して実行したら動くから、temp にある exe がローカルディレクトリのファイルに書き込みするとヒューリスティック検知が危険と判断してるんだな、多分

**デフォルトの名無しさん** · 2021/02/03(水) 21:45:23.85

>>347
> あとgithubからcloneしてこなくても go run できるのは意外と便利

これどゆこと？？

**デフォルトの名無しさん** · 2021/02/03(水) 22:46:07.77

>>348
この例だと statik を使うとき、go.mod に github.com/rakyll/statik を追加しとくじゃない
ここで、statik でファイルを固めるために statik コマンドをビルドしなくても
$ go run github.com/rakyll/statik -f -src=static
と打つと実行できるの

でもノートン入れてると危険な動作だと判断されるんで、run じゃなく build して実行ファイル作らないとダメだった

**デフォルトの名無しさん** · 2021/02/03(水) 23:03:33.06

このテクニックは
https://qiita.com/yaegashi/items/d1fd9f7d0c75b2bb7446#%E3%82%B5%E3%83%BC%E3%83%89%E3%83%91%E3%83%BC%E3%83%86%E3%82%A3%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E3%82%B8%E3%82%A7%E3%83%8D%E3%83%AC%E3%83%BC%E3%82%BF%E3%82%82-go-run-%E3%81%A7%E5%AE%9F%E8%A1%8C%E3%81%99%E3%82%8B
で知った

**デフォルトの名無しさん** · 2021/02/04(木) 00:47:53.46

>>349
ほーー！これ知らなかった。有益な情報ありがとう！

**デフォルトの名無しさん** · 2021/02/06(土) 07:34:59.64

importで現在のpackage宣言からの相対パスが使えなくなったのはクソ仕様変更だと思う
おのれ Russ Cox

**デフォルトの名無しさん** · 2021/02/06(土) 07:40:15.26

具体的に恨んでることは、あるサイトのコードを使い回して別のサイトのコードを書くとき、import を全部修正しなきゃならん
というかしてる
Linux ならまあ sed で置換すればなんとかなると思うけど、Windows で開発してるし

**デフォルトの名無しさん** · 2021/02/06(土) 07:42:46.96

あ、元のサイトの一部のコードは使い回すために go get して import してるから、sed でも面倒だわコレ

**デフォルトの名無しさん** · 2021/02/06(土) 07:48:05.22

なんか上手いことやってくれるツールってあるの？

**デフォルトの名無しさん** · 2021/02/06(土) 10:01:04.65

タダで使わせてもらってるくせに糞とか恨むとか
そういう心根だから日本はソフトウェア技術で海外に負けるんだよ

**デフォルトの名無しさん** · 2021/02/07(日) 03:51:41.73

タダで使わせてもらってるじからって大人しくしてるほうが進展しないと思うよｗ
もちろん活発にフィードバックが最善だが

**デフォルトの名無しさん** · 2021/02/07(日) 17:49:54.31

趣味でいじってて、検索に使うAPIを作ろうとしてるんだけど
関数の動的な引数について

ぐぐると出てくるFunctional Option Patternってどれくらい使われてるのかね
structをポインタで渡す（nil判定のため）でいいかなと思い始めてるんだけど

**デフォルトの名無しさん** · 2021/02/07(日) 19:19:28.11

>>358
たまに見るけど、エディタのコード補完と相性悪くてどんなオプションがあるのかがクッソ分かりにくい
個人的には大嫌い

**359** · 2021/02/07(日) 19:21:38.26

Functional Optionの話ね
補足

**デフォルトの名無しさん** · 2021/02/07(日) 19:31:24.83

structをポインタで渡すという一文で、わかってるのかな？という疑念が
FOP はざっくりと、アレンジする対象のオブジェクトを受けて内容を好きに設定する関数を、引数として渡す手法

ここでその関数の引数に対象structのポインタじゃなく実体渡しで受けるようにすると、コピーを書き換えちゃう事になるから設定しても動かない
ポインタで渡す以外の話にはならない

**デフォルトの名無しさん** · 2021/02/07(日) 19:38:47.51

もしかしてstructをというのは、FOPではなくオプション用のstructを用意するという話か

**デフォルトの名無しさん** · 2021/02/07(日) 21:18:42.15

>>359-360
どもども
サンプル見ても、準備する関数とか増えるから
スコープのためにimportのためにディレクトリのネストもう一個深くしないときついかなとか
色々めんどくさそうだった

>>362
そういうことです
手法として
・そもそも関数を別に切ってしまう（一番簡単だけどメンテがめんどい）
・引数を関数のために定義したstructのポインタにする
・FOP
という3つが挙がってた

**デフォルトの名無しさん** · 2021/02/08(月) 14:27:57.38

13年目のGo言語 - Steve Francia氏との対話から見えたそのエコシステム、進化、そして未来
https://www.infoq.com/jp/articles/go-language-13-years/

**デフォルトの名無しさん** · 2021/02/10(水) 23:54:39.22

18か月毎に、Goのユーザベースは2倍に膨れ上がっているのです。これはつまり、今日行われる変更は、5年前に比べて10倍の人々に影響を与える、という意味になります。

**デフォルトの名無しさん** · 2021/02/10(水) 23:55:51.44

Goが現在備えている依存管理は素晴らしいものですが、おそらくは5年前に実現するべきものでした。
この遅れが難しい問題をより難しくして、結果的に必要以上のストレスをコミュニティに起こしているのです。

同じように、現在開発を進めている大きな言語変更がジェネリクスです。これもコミュニティに大きな影響を与えるでしょう。
もし最初からすべてをやり直すことができて、この機能がいかに重要かを事前に理解しておくことが可能だったならば、おそらく7年前から本格的な開発を始めておきたかった、と思っています。

**デフォルトの名無しさん** · 2021/02/10(水) 23:56:43.35

言語として不足している唯一の大きな機能はジェネリクスです。先程も話したように、現在はこの開発に注力しています。

**デフォルトの名無しさん** · 2021/02/10(水) 23:58:38.65

・Goは優れた既定言語(default language)で、システムやサーバ、API、デーモン、データベース、Webサイトなどに適しています。Goはパフォーマンスと開発者の生産性を、高いレベルで両立させています。

・Dart + Flutterは、GUIベースアプリケーション(モバイルおよびデスクトップ)に適しています。Flutterは、複数のOSとフォーマットで動作する単一クライアントアプリケーションの記述というアイデアを、高いレベルで実現しました。

・Rustは、詳細なコントロールが必要な場合に適しています。低レベルな処理やカーネルなどです。Rustは精密性に優れていますが、その分、複雑さは大きくなります。このトレードオフが理に適っている場合もあります。そうであれば、Rustが最適です。

**デフォルトの名無しさん** · 2021/02/10(水) 23:59:45.15

Goは1度の週末で学べますし、2週間あればプログラミングに習熟することができます。もっと早い人もいるでしょう。他のいくつかの言語で経験があれば、Goは非常に短期間に習得できます。

Goを導入した企業と会った時に、彼らが一貫して話してくれることのひとつが、Goは習得の容易な言語だ、という点なのです。

**デフォルトの名無しさん** · 2021/02/11(木) 02:00:07.60

ジェネリクス結局どうなるんだよ

**デフォルトの名無しさん** · 2021/02/11(木) 03:54:00.93

議論の末リジェクトされたって結構前に見たけども

**デフォルトの名無しさん** · 2021/02/11(木) 06:20:02.21

あったら便利かも知れないけど、無くても不便を感じてないんだよな
多分、普段に書いてる案件の方向性の違いじゃないかな
ライブラリ書きな人は欲しがるのかも

**デフォルトの名無しさん** · 2021/02/11(木) 06:24:20.93

Webアプリだと必要なケースはほぼないかな
複雑なデータ構造を扱う分野とか数値計算なら必要だろうね

**デフォルトの名無しさん** · 2021/02/11(木) 07:33:17.81

複雑なデータ構造というより、多様なクラスじゃないか？
クラスが異なるが構造は同じ、といった場合に処理を使い回すための機能だから
たとえばList<Animals>とか

**デフォルトの名無しさん** · 2021/02/11(木) 09:48:01.53

https://github.com/golang/go/issues/43651
spec: add generic programming using type parameters #43651
Labels: Proposal Proposal-Accepted Proposal-FinalCommentPeriod

アクセプトされたぞ

**デフォルトの名無しさん** · 2021/02/11(木) 09:52:52.27

あと議論の末リジェクトされたのはエラーのキャッチでは？

https://github.com/golang/go/issues/43777
proposal: Go 2: catch error handler #43777

**デフォルトの名無しさん** · 2021/02/11(木) 10:26:29.66

>>375
おお！承認されたのか
ところで、go2はいつくるの？

**デフォルトの名無しさん** · 2021/02/11(木) 11:34:18.35

https://blog.golang.org/generics-proposal

v1.18β（今年末）にはジェネリクスが入ってる予定だそうだから
そこからしばらくexperimental feature扱いになるとして
だいたいv1.20（再来年頭）かそこらでexperimentalじゃなくなってv2.0にするんじゃないか

まあこれは一番順調に行ったらって予想だけど

**デフォルトの名無しさん** · 2021/02/11(木) 12:43:54.91

>>375
ファイナルフュージョン承認！

**デフォルトの名無しさん** · 2021/02/11(木) 13:01:17.98

実装難しそうだから相当先だろうな
特殊化をコンパイル時にやるのか実行時にやるのかすら決まってないみたいだし

**デフォルトの名無しさん** · 2021/02/11(木) 14:10:14.32

Javaのジェネリクス導入時みたいに、総称型コレクションの利用で警告を出すような真似はしないで欲しい

**デフォルトの名無しさん** · 2021/02/11(木) 14:18:10.77

なんで Java ではデフォルトで「raw型の使用を無視」にしとかないで、探して無視に指定するまでうるさく警告を出すことにしたんだろう

**デフォルトの名無しさん** · 2021/02/12(金) 03:53:22.35

結局仕様はほぼJavaと同じか

**デフォルトの名無しさん** · 2021/02/12(金) 13:19:24.35

エラーキャッチリジェクトかよ・・

**デフォルトの名無しさん** · 2021/02/12(金) 19:55:13.35

issue の本文で
func xxx() xxx, error
とか
nill
とか、go 使ってないような奴なのは見え見えだし、
妥当じゃないか？

**デフォルトの名無しさん** · 2021/02/13(土) 01:19:56.35

ジェネリック馬鹿を排除できるだけでもgoを採用する意味あるわ。

**デフォルトの名無しさん** · 2021/02/13(土) 02:05:58.45

実務でgoやってみたいけど今は未経験の募集あまりないな

**デフォルトの名無しさん** · 2021/02/13(土) 02:18:54.12

ジェネリクス反対派って結局何がしたかったんだろう
訳がわからん
言語の設計者でもないのに

**デフォルトの名無しさん** · 2021/02/13(土) 03:56:17.09

>>386
お薬かな

**デフォルトの名無しさん** · 2021/02/13(土) 05:14:35.81

Java ではジェネリクス過激派による強制で多いに迷惑したから

**デフォルトの名無しさん** · 2021/02/13(土) 08:17:20.01

>>383
Javaと同じってどこが？

**デフォルトの名無しさん** · 2021/02/13(土) 09:26:28.23

正直、意味があるのか俺には理解できない
他の言語は継承による拡張なので共変反変が意味を持つ
でも go は継承による関係じゃなくて、インターフェースを具備しているかどうか
元々がインターフェースさえ合致していれば可換なのだから型パラメータには意味がない
そう思ってしまう

どうしても型パラメータが必要な用例、それを目立つように挙げて貰いたい

**デフォルトの名無しさん** · 2021/02/13(土) 10:56:01.28

Goで便利なのはsort関数とかmap関数なんかではないの？
今まで型ごとに書くしかなかったんだし。

**デフォルトの名無しさん** · 2021/02/13(土) 12:32:44.33

まずmapはインターフェースをキーとしても値としても使えるから問題にならない
ソートもsort.Interfaceを具備したコレクションでソートするから、Swapとかのための比較可能な値を返すメソッドをインターフェースで持てば良い

構造体はただの入れ物に過ぎないよね

**デフォルトの名無しさん** · 2021/02/13(土) 12:40:39.64

インターフェースで構造体の多態性を確保してるから、それが既に型パラメータ以上の柔軟さを持ってる
なんでインターフェースよりも性質的に劣ってる型パラメータを導入しなきゃなんないの？
頭のいい人が、それでも導入が必要だと判断したのだから、そこには理由があるはず
でも頭が悪いから、俺ではissueで見つけられなかった

**デフォルトの名無しさん** · 2021/02/13(土) 12:54:38.86

>>394
インターフェイスを使ってしまうと毎回型チェックしないといかんし、コンパイル時に縛りもかけられんでしょ。
テストで網羅するといっても、ユーザに使ってもらうライブラリなんかではそうもいかん。
静的解析でもうまくいかんこともあるし、柔軟性を持ちたいのではなくて、コンパイル言語として担保したいんじゃないか？
俺は今まで型ごとに関数作ってたけど、インターフェイスでなんとかしてたって事？それも極端だな。

**デフォルトの名無しさん** · 2021/02/13(土) 13:03:01.32

>>396
というかインターフェースを型パラメータみたいな物として使っていて問題なかったと言ってるんだよ
機構として使い回すために、その機構に使いたかったらインターフェースを実装する
ソートの機構が使いたかったらsort.Interfaceを実装するでしょ

**デフォルトの名無しさん** · 2021/02/13(土) 13:27:48.18

>>396
そもそも何で型チェック？
メソッドの挙動やらが違うのに同じインターフェースを使ってるのか？
Javaとかの型パラメータでも、まさか中でキャストして使ってるのか？

偶然にインターフェースを実装してしまったケースなんて想定しても仕方ないと思う
それは設計ミスだから
区別用にダミーのメソッド生やしとけば？

**デフォルトの名無しさん** · 2021/02/13(土) 13:30:40.12

goは組み込みで要素が型付けされた動的配列と連想配列を持ってるから、他のコレクションはあまり必要ないんだよね
それらでカバーできないようなケースってそもそも大抵は特殊な状況なんで、汎用的なコレクションではなくアプリの要請に合わせて独自に作るのが自然

**デフォルトの名無しさん** · 2021/02/13(土) 13:45:02.72

んな意味不明なジェネリクスより
>>251 のバグを直して欲しいんだよな

**デフォルトの名無しさん** · 2021/02/13(土) 13:54:07.96

>>397
ジェネリクスはロジックを使い回すのためだけにあるわけではないと思うよ。
Sortableなんてinterfaceを実装した配列を引数に受ける関数の戻り値の型は何になる？
Sortableの配列が帰ってきても無意味でしょ。

>>398
中でキャストするとかは意味不明じゃないか。
ジェネリクスがない頃のObjectの配列を受けざるをえないメソッドはまた違っただろうけど。
ダミーのメソッドとか完全に意味不明。

**デフォルトの名無しさん** · 2021/02/13(土) 14:07:47.74

>>401
Sortableの配列を返すので正しい
文意からソート結果だろ？

君が型チェックしなきゃならんとか意味不明な事を言い出すからエスパーしたんだよさせるなよ
インターフェースならメソッドを呼ぶだけだから型チェックなんて話は出てこない
型チェックするってことは実体に変換しなきゃならんという話だろ

そうでない場合に考えられるケースとして、偶然に同じインターフェースを実装してしまった構造体を、偶然に渡してしまうコーディングミスを考えているとエスパーしてあげた
そんな阿呆な設計をしてるなら、引数としてるインターフェースにダミーのメソッドを生やしとけば、別のインターフェースになるから誤って渡すミスは無くなる
エスパーさせるなよ

**デフォルトの名無しさん** · 2021/02/13(土) 14:21:47.27

>>402
ソート可能なインターフェイスを受けてソート可能なインターフェイスが帰ってきても何も得しない。

[T Sortable]な関数の返り値は[]Tで十分でしょ。
結果がもう一度ソート可能かなんか必要な情報でない。

intがSortableだとして、返り値が[]Sortableだと、結果は型チェックしないとだよね。
[]intが直接帰ってきた方が効率的だし、無駄なコードではないよね。
やってることも自明。

mapとかflattenなんかなんかはジェネリクス使えないと使い物にならんと思うが。

エスパーするならジェネリクスの使いみちをエスパーしなよ。

**デフォルトの名無しさん** · 2021/02/13(土) 14:23:26.25

単一の引数だけなら>>395のようにインターフェースで代用できるけど
複数の引数や戻り値の型を合わせたいという場合は型引数が使いたいよね。

**デフォルトの名無しさん** · 2021/02/13(土) 14:34:17.23

>>398
キャストしないといけないの理解できてないあたり、型パラメータとインターフェースでの実装の違い理解してなさそう

**デフォルトの名無しさん** · 2021/02/13(土) 15:24:34.05

>>404
複数の別のインターフェースを引数に持たせれば問題ないでしょ
それぞれが型パラメータとして機能するんだから

戻り値も同じ………いや、戻り値に関しては一概には言えないのか
でも実体ポインタを返すメソッドは>>251のバグに引っ掛かるんで使いたくない
→ 戻り値の実体ポインタはインターフェースを備えてるならば、本来は反変でアップキャストされてインターフェースを返しているとも判断されるべき
このバグで多態が機能しなくなるから使いたくない
具体的にはシグネチャが違うため、変種をコレクションに混在して格納できない

ジェネリクスを導入して個別に実体ポインタを返せるようにした時に同じ現象になるはず
このメソッドを持つジェネリクスな構造体は、それぞれ可換でないので多態が適用できない
コレクションに混在させられない

インターフェースを返す設計ならば、それらは実体は異なっても多態が機能してコレクションに混在格納できる
よって、インターフェースを返す方が設計として抽象度に優れている

以上の論旨から、ジェネリクスはインターフェースの下位互換だとしか見えない

**デフォルトの名無しさん** · 2021/02/13(土) 15:35:29.60

>>406
違くて、2つの引数があるときにその型が同じであってほしい場合とかね。

**デフォルトの名無しさん** · 2021/02/13(土) 15:42:03.45

>>407
その場合には同じインターフェースの二つの引数を持つことによって問題がある事例について具体的に指摘してくれ
型が同じことは保証されてるぞ

**デフォルトの名無しさん** · 2021/02/13(土) 15:44:29.17

>>406
インターフェイスはインターフェイスで使えば良くて、ジェネリクスで効率的にできたり型を自明にできる部分はジェネリクスを使えばよいでしょ。
今でもコードジェネレータなんかで作ってる部分もあるだろうし。

どちらかがあれば原理的にどちらかが不要なのと、
どちらかがあれば片方は作ってはいけないのは別。

Sortとか、mapの[T,U]のKeyのみ、Valueのみを([]T,[]U)と、配列として返す関数なんか書こうと思ったらジェネリクスが無いと型チェックの嵐でしょ。
確かにキャストではないけど、型チェックもノーコストではないよ。

ジェネリクスのある言語使った事無いんじゃないの？

>>403のケースなんかはどうするん？型チェックすんの？

**デフォルトの名無しさん** · 2021/02/13(土) 15:45:29.07

>>408
map[T]Uを受けて、[]Tと[]Uを返す関数。

**デフォルトの名無しさん** · 2021/02/13(土) 15:51:17.90

とか顔真っ赤にして主張してきたけど、具体的にちょっと面倒な事例に自分で気づいてしまった

new() が厄介だな
new の代わりにインスタンスを生成する factory 一時クラスを外から渡してやれば解決するんだけど面倒ではある

**デフォルトの名無しさん** · 2021/02/13(土) 15:56:48.27

>>408
結局は返り値の話に帰着するのかもしれないけど (T, T) -> T な関数が欲しいとかね。

**デフォルトの名無しさん** · 2021/02/13(土) 16:10:36.47

返り値に関係なかったら、Tとそれに対するfunc(x T)を受ける関数とかかなぁ。

**デフォルトの名無しさん** · 2021/02/13(土) 16:10:51.14

>>410
納得した

メソッド引数のシグネチャが異なるものを一本化して書けるわけか
確かにインターフェースじゃmap[T]Uを引数とした共通メソッドは書けない
T,Uがインターフェースだとしても、それぞれのインターフェースの組ごとにメソッドが必要になるから

**デフォルトの名無しさん** · 2021/02/13(土) 16:12:52.49

>>414
伝わってよかった。逆もしかり。
[]Tと[]Uを渡してmap[T]Uを返してくれる関数も。
Pythonでいうとzip関数的な。

**デフォルトの名無しさん** · 2021/02/13(土) 17:03:51.51

>>415
JavaだとProxyを使って何でも解決するという黒魔術的解決手段があるのが恐ろしい
デバッグ用だよねとか思ってると struts とかwebフレームワークのソース読んだ時に、インタセプターとかで普通に使われていて更にビビる