Go language part 3

**デフォルトの名無しさん** · 2019/10/17(木) 21:38:04.78

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

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

日本語訳
http://golang.jp

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

**デフォルトの名無しさん** · 2020/03/28(土) 19:28:58.20

Cでlongjump使いまくってたタイプじゃね？

**デフォルトの名無しさん** · 2020/03/29(日) 01:28:26.45

>>352
だから何？
お前が見通してくれるわけじゃないなら黙ってろよ

**デフォルトの名無しさん** · 2020/03/29(日) 01:31:05.49

顔真っ赤だぞｗ

**デフォルトの名無しさん** · 2020/03/29(日) 01:58:14.56

由緒正しい2chの流れだな

**デフォルトの名無しさん** · 2020/03/29(日) 09:36:10.09

>後で扱うデータの仕様変更があってエラーハンドリングが必要になったときに
>ガッポリその部分覆ってまとめてエラー扱うってのが一切できないんだよな

これ自体が例外ありきの発想のように思う

**デフォルトの名無しさん** · 2020/03/29(日) 09:50:09.28

Goだと極一部の簡単な関数を除けば基本的にerrを返すから、後でerr発生箇所が増えても影響は関数一つだけだろう
それが問題になるようなアホみたいに長い関数を書いてるならそれ以前の問題だな

**デフォルトの名無しさん** · 2020/03/29(日) 10:32:30.34

errorを返すように関数を変えたなら
call siteをすべて変更しなきゃいけないってのは仕方がない
それは考え方の違いだから将来的にも修正されることは無いと思われる

ただcall siteで単にエラーをpropagateするだけなのに
毎度毎度`if err != nil`書かせるのは頭悪いしノイズ比が高すぎる

開発陣も問題だと思ってるからどうにか改善しようとしてるけど
下の提案はダメになったからどんなに早くてもあと数年は現状維持だろうね
https://go.googlesource.com/proposal/+/master/design/go2draft-error-handling-overview.md
https://go.googlesource.com/proposal/+/master/design/32437-try-builtin.md

**デフォルトの名無しさん** · 2020/03/29(日) 12:46:52.07

vscode で if err!=nil のブロックをデフォルトで折り畳んでくれたら、おれは嬉しい

**デフォルトの名無しさん** · 2020/03/30(月) 01:14:32.45

err返すくせに型に現れないのは正直ゴミ

**デフォルトの名無しさん** · 2020/03/30(月) 01:28:23.67

またお前か

**デフォルトの名無しさん** · 2020/03/30(月) 03:48:40.78

またお前かって初めてこのスレに書き込んだんだが
そういって一生ゴミ仕様から目を背け続けろな

**デフォルトの名無しさん** · 2020/03/30(月) 09:45:11.16

わかったよ、ゴミ

**デフォルトの名無しさん** · 2020/03/30(月) 10:59:24.22

errさんイライラwwwwwwwwwwwwwwwwww

**デフォルトの名無しさん** · 2020/03/30(月) 11:27:55.23

errさんはPHPしか触ってこなかったから気にしないんだよ

**デフォルトの名無しさん** · 2020/04/01(水) 02:09:08.12

Cだともっと酷いよ？
戻りでエラー返すと本来の戻り値が潰れるから
&errorとかいう独自定義のエラー用構造体を引数に毎回渡す
これに比べたら天国

**デフォルトの名無しさん** · 2020/04/01(水) 10:12:05.33

Goは標準ライブラリが豊富っていうけどどこらへんが豊富なの？
Goは並行処理が得意なのに並列処理が得意とか実際に触ってるわけでもないのに書く人多いから豊富ってのも嘘なんじゃないかと思ってる

**デフォルトの名無しさん** · 2020/04/01(水) 10:14:23.29

そうだよ嘘だよ。じゃね～さよなら

**デフォルトの名無しさん** · 2020/04/01(水) 10:49:13.13

>>367
GetLastError
エラーを取得するには関数を使います

**デフォルトの名無しさん** · 2020/04/01(水) 11:07:46.88

GetLastError() って Windows OS のみ？

**デフォルトの名無しさん** · 2020/04/01(水) 12:24:45.60

Cだと戻り値でデータ返したりエラーコード返したりやりたい放題で一貫性が無さすぎ
Javaとかはtry catch地獄
Cでレジスタで戻り値返さずに複数値返せる設計にしてれば標準となって皆幸福だったのに

**デフォルトの名無しさん** · 2020/04/01(水) 12:30:21.07

最近のは(小さい)構造体なら返せるやろ
デカいのは無駄だし
mallocしたのだと解放が面倒だが

**デフォルトの名無しさん** · 2020/04/01(水) 14:22:10.98

>>372
ハードウェアの構造無視しすぎ。
それでみな幸せならとっくにそうなっとるわ。
cでもスタックの使い方の規約なんて昔と相当変わってる。

**デフォルトの名無しさん** · 2020/04/01(水) 14:28:21.58

スレ違い

**デフォルトの名無しさん** · 2020/04/01(水) 16:03:45.28

>>370
Windowsの作法やん
それにグローバルなエラー情報とか論外

**デフォルトの名無しさん** · 2020/04/02(木) 08:03:50.65

>>374
ん、その昔の段階で戻り値の返し方で言語仕様的に一工夫してくれてたらという正直ムチャ振りなレスだったんだけど

**デフォルトの名無しさん** · 2020/04/02(木) 17:36:34.36

Goって複数の戻り値はスタックにおいてるのかね？
その辺どうなってるんだろう

**デフォルトの名無しさん** · 2020/04/02(木) 21:18:47.20

コンパイル時にサイズが決まるならスタックに積んで返すのは難しくないだろう。
今どきCでも構造体を返したりできるし。

**デフォルトの名無しさん** · 2020/04/14(火) 13:45:39.46

老人介護用言語すぎてストレスしかない
なんで今の御時世にこんな微妙な言語使わなければならんのだ
ポインタ意識したりするよりドメイン層の設計に時間を割いたほうがマシだわ
はぁ…

**デフォルトの名無しさん** · 2020/04/14(火) 13:52:00.63

無理して使わんでもええがな

**デフォルトの名無しさん** · 2020/04/14(火) 13:58:34.65

どの言語にも言えるけど
全ては実験台でしかない

**デフォルトの名無しさん** · 2020/04/14(火) 14:26:34.45

権限だけ持ってる考えなしの馬鹿が採用を決めたせいで無理して使うしかないんだわ
トラップ多くてその調査のせいで学習コスト跳ね上がるし
並列処理簡単って動かすだけならそりゃ簡単だろうが…ってレベルの完成度の低さで
CPUフルで使い切るような事やらせようと思ったら面倒さも管理も段違いの面倒さ…

愚痴はまぁともかく、structって脳死して全部ポインタで扱うほうがいいんけ？
というかstructに実装持たせるような意識なんて投げ捨てて旧石器時代を目指すほうが良い言語？

**デフォルトの名無しさん** · 2020/04/14(火) 14:32:51.20

あくまで関数が主体であり、structはオブジェクト指向的な実体というより、単なる文脈と考えればいい
Rustも同様の考え方だし、C#なんかも最近はそういう方向へ進みつつある
善し悪しはともかく最近の流行りではある

**デフォルトの名無しさん** · 2020/04/14(火) 14:38:21.41

>>383
基本的にはちょっと楽なCだからね
まともなC使いは第一引数にオブジェクトのポインタわたしてたし
継承も構造体使って同じことしてた
むしろC使いは理想的な言語を作ってくれた！と思ってる

**デフォルトの名無しさん** · 2020/04/14(火) 17:35:01.14

>>383
CPUフルに使いきるなら素直に別プロセスにして上位レイヤーで分散するよう工夫したほうが結局コスト安く済むような印象がある
まあWeb系じゃないならそうは行かない場合もあるんだろうけど

**デフォルトの名無しさん** · 2020/04/14(火) 17:47:59.69

ハイパースレッディング的にCPUを並列化したいならGoなんで使うものじゃないよ

**デフォルトの名無しさん** · 2020/04/14(火) 17:55:25.26

simulationライブラリで純粋な関数式プログラミングをする
ttp://x0000.net/topic.aspx?id=3631-0

UIライブラリ (C#, 2D) を作ったよ
ttp://x0000.net/topic.aspx?id=3688-0

連続と離散を統一した！
ttp://x0000.net/topic.aspx?id=3709-0

4Dエンジン
ttp://x0000.net/topic.aspx?id=3677-0

matrixのライブラリ
ttp://x0000.net/topic.aspx?id=3711-0

ある強力なFor関数
ttp://x0000.net/topic.aspx?id=3630-0

SQLライブラリ
ttp://x0000.net/topic.aspx?id=3675-0

**デフォルトの名無しさん** · 2020/04/14(火) 21:22:08.02

>>383
コア数分のgoroutineでCPU使ってくれない？なにかそんなに面倒なことあったっけ？

**デフォルトの名無しさん** · 2020/04/14(火) 22:32:46.86

golangのポインタ周りはrangeでイラっとしたくらいだわ
他はわかりやすいし使いやすい印象

**デフォルトの名無しさん** · 2020/04/15(水) 00:46:12.61

いやいや・・ポインタも構造体の実体からもアクセスがどっちも . とか
トラップすぎて草はえるわ
そりゃさだいたいは問題ないよ、だけどな大体のとこは良いけどたまーに
罠にハマるっていうパターンの問題が一番やっかいな罠になるもんなんだよ
そんな中途半端なことするぐらいならいっそハナから面倒なままにしてくれるか
あるいはしょうっちゅう問題が起きるから常に注意して書く必要がある、ぐらい
のほうがよっぽどマシ
GO言語はこの「だいたいいいけどたまに罠」がクソ多すぎてほんとクソ言語だよ

**デフォルトの名無しさん** · 2020/04/15(水) 01:09:47.19

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

**デフォルトの名無しさん** · 2020/04/15(水) 02:17:30.11

全部ポインタにしてるわ
現代のアーキテクチャからしたら明らかに遅くなりそうだが
C脳だから全部ポインタw

**デフォルトの名無しさん** · 2020/04/15(水) 03:27:51.37

全部ポインタは無駄処理増えてパフォーマンス的に良くないようだけど
そうした方が言語トラップを回避できる可能性が高いって時点でうんこであることは間違いないと思うよ
コードをひと目見てすぐ問題があると判断できないようなトラップが散りばめられてて学習コストが低いとか嘘だわ

インポートも微妙、名前ぶつかりすぎでローカル変数名が半端になっていく
エクスポートの仕様も半端、プロパティとかないから構造体のフィールドは全開放で
扱う側に全責任が委ねられてしまうしパッケージ変数とか公開した日にゃノーガード戦法しかない
その割にリフレクションでの制限だけはクソきつくて非エクスポート関数の参照や値の変更は実質ほぼ不可能
あとエラーもうんこ
goのerrorをバケツリレーしていくような実装って、結局のところJavaでいうところの throws Exception を
全メソッドに書いちゃうようなゴミ実装をより面倒くさい記述にしただけみたいな感じ
エラーの中身が型として読み解けないせいで意識しないといけないスコープが広がりすぎるから超めんどくさい
エラー処理をせずもみ消したいときにtry/catchがいらないみたいな、死ぬほどどうでもいい利点くらいしかひねり出せない

言語の決定権がなく仕方がなく使ってるけど、全てを把握できてて自分以外が触らないような
単機能の小さいツール作るくらいの用途くらいでしか使いたくない言語って感じで、書くほどストレスが溜まっていくぜ…
これを絶賛する人たちが本当に最高だと思ってるのかマジでわからんくなる…

**デフォルトの名無しさん** · 2020/04/15(水) 04:05:18.88

今Go使ってる人はなんちゃっての人は少ないからねえ
まともにGoやってますって人の少なさよ

**デフォルトの名無しさん** · 2020/04/15(水) 07:24:14.59

はて、ポインタで無駄処理ってのは聞いたことないな

アセンブラのレベルから見ると、実体って概念は配列要素へのアクセスを先頭からの相対位置で行うという、限られた局面でしか現れないもの
あ、自動変数の実現としてスタックを積んでスタックボトムからのオフセットを使用するのは一般的ではあるか
ともかく実体渡しはCとかあの辺りの言語で実装された二次的なもので、あくまでポインタの糖衣構文じゃないの？

俺が最近のCPUを知らないからトンチンカンなのかな？
ベクタ計算がプリミティブに使われない限り、よりマシンに近い記述がポインタだと理解しているんだが

**デフォルトの名無しさん** · 2020/04/15(水) 11:39:38.66

せっかくのキャッシュなのに
キャッシュ捨てまくりが発生

**デフォルトの名無しさん** · 2020/04/15(水) 11:42:52.38

ちゃんと読んで答えてるっぽい奴居て草
今君は川に流れてるウンコを態々拾いに行ったのだ
ばっちぃから触っちゃ駄目だろ、ちゃんと反省しろよ

**デフォルトの名無しさん** · 2020/04/15(水) 13:07:39.95

>>220-221

**デフォルトの名無しさん** · 2020/04/15(水) 19:49:21.31

>>399
それが何で遅くなるのか理解して言ってるか？
ポインタが無駄な処理になるからじゃなく、メモリアクセスとメモリ管理を最適化するため
実体配列のニッチな需要があるかぎりは実体は廃止できないという意見

正直、そういう需要なんて切って捨てていいと思う
Javaみたいに

**デフォルトの名無しさん** · 2020/04/17(金) 18:19:15.53

Javaはスレッド跨ぐ場合はスレッドごとにコピーした値をキャッシュしたりはしているし
それで起きる問題を回避するための手段も用意されてる

Goがただ面倒くさいゴミ言語って話でJavaを例えに上げるのは理解してなさそうに見えちゃわない？

**デフォルトの名無しさん** · 2020/04/17(金) 18:27:51.48

だって Java thread って context switch が遅いんですもの…（仕方ないけど）

**デフォルトの名無しさん** · 2020/04/18(土) 03:21:59.85

皆んとこインフラでGo使ってないんか？
クラウドならGo一択だと思ってた

**デフォルトの名無しさん** · 2020/04/18(土) 08:06:56.22

Go製のキラーアプリであるDocker
それをRustで書き直すって話無かった？もう公開されてる？
厳密なコンテキスト操作がGoでは実装できないからって
それとも自分の勘違い？

**デフォルトの名無しさん** · 2020/04/18(土) 10:25:08.47

Dockerの記述言語なんて使う分には関係ないからキラーアプリとは違うような。

**デフォルトの名無しさん** · 2020/04/18(土) 17:50:04.38

コンプライアンスに即した範囲でできるテレワークって事で
最近「他社ゲームのアーキテクチャを調査」ってタスクをやったんだけど
Golangは無いね。Node.jsばっか
個人的にはgo使いたいから、家にいる期間になんか一個作りたいけどなぁ…。

**デフォルトの名無しさん** · 2020/04/18(土) 18:26:19.74

ゲーム会社でもコンプライアンスの関係でテレワークできない業務なんかあんの？
少なくともゲーム会社よりはお堅い会社に勤めてるけど、全部在宅で何の問題もないな
コードは主にNode.js(オンライン)とPython(バッチ)で、オンラインについてはGoへの書き直しを進めてる

**デフォルトの名無しさん** · 2020/04/18(土) 18:31:11.51

>>407
外注だからね

**デフォルトの名無しさん** · 2020/04/18(土) 18:45:55.45

JavaとかScalaで作ってたものをGoに置き換えるみたいな流れは割とある

**デフォルトの名無しさん** · 2020/04/18(土) 19:32:53.45

windowsとlinuxで動かさなきゃいけないアプリをJavaで書いてて
全く問題なかったんだけど
実質有償化に伴って他の言語で書き直そうかと思ってるけど
Goってwindows上でも安定して動くのかね？
ちなみに24時間稼働しっぱなしのアプリ

**デフォルトの名無しさん** · 2020/04/18(土) 20:00:40.33

そんな君にはC#おすすめ

**デフォルトの名無しさん** · 2020/04/18(土) 20:18:48.00

まあC#だろな

**デフォルトの名無しさん** · 2020/04/18(土) 20:31:40.92

C#ってlinux上ではmonoとか使うわけでしょ？
流石にないわー

**デフォルトの名無しさん** · 2020/04/18(土) 20:33:06.29

>>406
CATSってスマホゲーがサーバーにGoを使ってるらしい
サーバーにちょくちょくアクセスしながら動作してるんだが、めっちゃ速いよ
この辺はスピンアップが爆速な恩恵なのかも

**デフォルトの名無しさん** · 2020/04/18(土) 20:41:10.89

>>406
フロントはNodeでバックエンドがGoだと
外からじゃ調べよう無いよね？

**デフォルトの名無しさん** · 2020/04/18(土) 20:51:17.88

>>413
ひどい無知

**デフォルトの名無しさん** · 2020/04/18(土) 20:57:00.49

>>413
何言ってんのこいつ

**デフォルトの名無しさん** · 2020/04/18(土) 21:20:46.34

>>414
個人的興味でちょっと見てみるわ

>>415
そういう調査じゃなくて
スライドシェアとかの公開資料のまとめ
正直引き続き契約延長いただいてありがとうございますというレベル
この状況がまだ続くんなら、流石に家でもほんとに作業するように変わるんじゃないかと思うけどね
または切られるかだな…

**デフォルトの名無しさん** · 2020/04/18(土) 21:42:45.13

今からC#勧めるってお前ら悪い奴やな～

**デフォルトの名無しさん** · 2020/04/18(土) 22:33:18.98

今のC#知らない人多そう
特定の言語に拘らず積極的に情報収集した方がいいと思うけどね
スレチだからここまで

**デフォルトの名無しさん** · 2020/04/18(土) 23:45:31.62

今のC#センスいい言語になってると思うよ、俺も。

**デフォルトの名無しさん** · 2020/04/19(日) 00:11:47.49

たまには F# のことも思い出してあげて下さい

**デフォルトの名無しさん** · 2020/04/19(日) 19:53:26.80

だが断るっ！

**デフォルトの名無しさん** · 2020/04/22(水) 17:15:41.53

流石にJavaやScalaからGo移行とかになるとあまりの言語機能のゴミっぷりに開発者がキレそう
今までハサミつかって紙きってたのに石器渡されるようもんだわ

**デフォルトの名無しさん** · 2020/04/22(水) 17:57:25.70

　 /＼＿＿_／＼
／　／　　　ヽ ::: ＼
|　（●）,　、（●）、　| 　　／￣￣￣￣￣￣￣
|　　,,ノ(、_, )ヽ、,, 　 | 　＜　まーたはじまった
|　　　,;‐＝‐ヽ　 .:::::| 　　＼＿＿＿＿＿＿＿
＼　　｀ニニ´　 .:::／
／｀ー‐--‐‐―´´＼

**デフォルトの名無しさん** · 2020/04/22(水) 18:22:16.77

この言語はCでサーバを書いているようなニッチな要求の仕事を置き換えるんだろうな

なに？そんな仕事があるわけない？
…去年回って来ちゃってたよ、そんな仕事が
ミリ秒縛り要求で数十の機器の管制をするサーバ
当時はgo知らなかったんでgccで書いた

**デフォルトの名無しさん** · 2020/04/22(水) 19:29:43.68

リアルタイム性重視なら、GCあるGoは向いてないんじゃ
その用途で置き換えるならRustになりそう

**デフォルトの名無しさん** · 2020/04/22(水) 20:01:17.39

Goは半日で理解できたがRustは無理だった

**デフォルトの名無しさん** · 2020/04/23(木) 00:05:34.25

鯖は比較的余裕有るけど、クライアント側でGCが痛い子になる事はありそう
Rustは半日では無理だなぁ～、概念は直ぐ理解出来るけど書き方に統一感無さ過ぎてキレそう<'a>&'a *ref

**デフォルトの名無しさん** · 2020/04/23(木) 00:49:14.99

Rustは人類には早すぎる

**デフォルトの名無しさん** · 2020/04/23(木) 00:55:50.26

禿しく同意

**デフォルトの名無しさん** · 2020/04/23(木) 08:01:42.02

Rustはバカ速いとか聞くから覚えたいんだけど
学習コストもバカ高いよなぁ
CとかPascalやっててJavaを始めたときの倍くらい大変な感じがする
C#はJavaを丸パクりで基本構文ができてたから、１日

**デフォルトの名無しさん** · 2020/04/23(木) 08:06:05.23

そりゃあif文for文みたいなコードだけなら1日だろうよ

**デフォルトの名無しさん** · 2020/04/23(木) 08:41:47.89

rust、利便性のためにライフタイムの省略パターンとか作ったんだろうけれど、逆にわかりづらくなってるわ。

**デフォルトの名無しさん** · 2020/04/23(木) 10:29:03.11

>>433
クラスの定義の書き方とかもだよ
Javaでない言語のクラスの書き方は、クラス定義にはメソッドの宣言を書いて、定義の外で実装するスタイルが主流だった(他の言語には無いとは言わないが非主流)
これはC++とかObjectPASCAL、そしてGoもこちらのスタイルではある

C#では、基本的にデフォルト仮想なJavaメソッドに対して、デフォルトは非仮想って程度の差(充分にでかい差ではある、ちなみにジェネリックはまだない時分)
だから、覚えるというより慣れるのに１日
SalesforceのAPECはまた面白くて構文はC#以上にJavaなのにデフォルト非仮想だったかな
よく似た兄弟すぎて、仕事とプライベートそれぞれ違う言語で書いてると混乱する

**デフォルトの名無しさん** · 2020/04/23(木) 10:36:37.69

>>435
完全にコーダーの発想だな

**デフォルトの名無しさん** · 2020/04/23(木) 10:37:35.02

>>433
ああ、そういえばCとかではエントリがmain関数だったのが、クラスになっているスタイルもJavaで覚えた
そのためC#でもほぼ同じだから、そこで引っ掛かることが無かった
そういう観点であってifとかforなどの構文じゃないよ

**デフォルトの名無しさん** · 2020/04/23(木) 10:39:55.23

>>436
笑わせるなよ
学習コストの話なんだからコーダー視点に決まってるだろ

**デフォルトの名無しさん** · 2020/04/23(木) 10:55:34.68

キチガイに触ってしまったごめんなさい

**デフォルトの名無しさん** · 2020/04/23(木) 10:55:50.60

JavaとC#では技術スタックが全然違うだろう
サーバーの構築から通信方法からフレームワーク等の選定から何から、
そういう足回りを全部すっ飛ばして全部あらかじめ他人に与えられた環境を使って
「さあ、アプリケーションコードを書いてください」ならそら大差ないだろ
俺は436じゃないが「コーダー」ってそういう意味じゃないかな

**デフォルトの名無しさん** · 2020/04/23(木) 11:30:36.92

ハゲしくスレ違い

**デフォルトの名無しさん** · 2020/04/23(木) 14:11:43.18

出だしが学習コストの話で、人格攻撃やらサーバの構築とか的外れな事を言い出してくるやら
詭弁術だけはお得意なことはよくわかりました

**デフォルトの名無しさん** · 2020/04/25(土) 02:28:33.10

ギスギスしててワロ
Goは誰でもある程度のレベルくらいまでなら使いこなせる優しい言語

**デフォルトの名無しさん** · 2020/04/26(日) 19:49:45.56

ものすごく当たり前の落とし穴に落ちた

ファクトリから構造体アドレス返してたのをインタフェース返すように変更したらテストでコケた
キャストチェックのテストだったんだけど、レシーバのシグネチャが同じ別のインタフェースがあって、そいつにキャストできちゃった

インタフェースが同じなら同じものとして使えるってことは、そういう問題を想定しとかないとならなかった

**デフォルトの名無しさん** · 2020/04/28(火) 19:31:28.17

大きくなってきたんでパッケージを分割

設定とか全体を管理するAパッケージ
httpのリクエストを管理するBパッケージ
webAPIのロジックを管理するCパッケージ
ロジックのインスタンスは設定で作って、リクエストから呼び出して処理してもらう

さて、ここで落とし穴
Cパッケージから設定を参照するためにAパッケージをインポートすると import cycle not arrowed 発生
AパッケージではCパッケージをインポートして、ロジックのファクトリを呼び出してる

インポートの循環の制約とか、それは厳しすぎやしませんかね
第三の上位パッケージを作ればなんとかなるのかなぁ？

**デフォルトの名無しさん** · 2020/04/28(火) 20:20:55.63

arrowed ?

**デフォルトの名無しさん** · 2020/04/28(火) 20:31:42.46

>>445
Goに限らずモジュール境界はインタフェースで抽象化するもんじゃ？
そうしないとユニットテストつらい

**デフォルトの名無しさん** · 2020/04/28(火) 20:48:56.59

> 設定とか全体を管理するパッケージ
インターフェース云々以前に、そんなふわっとしたモジュール強度の低いパッケージが存在することが問題
設定なら設定で分けろ
設定はデータ構造自体がインターフェイスなんだからカプセル化とか要らん

**デフォルトの名無しさん** · 2020/04/28(火) 20:51:51.61

>>445
AからC呼び出すっておかしいだろ
設計やり直せ

**デフォルトの名無しさん** · 2020/04/28(火) 22:00:57.39

>>449
ロジックのインタフェースの実体を得るファクトリ関数なんだがおかしいのか？

でも、そもそもが設定情報のパッケージにシステムを管理するデータの生成を担わせてる設計が原因臭いとはうすうす
やっぱそこを別パッケージに分離して結合を弱めないとだめだな

**デフォルトの名無しさん** · 2020/04/28(火) 22:23:30.36

結局、日和ってロジックのインスタンスはCパッケージにシングルトンとして実装してBから呼ぶことでallowedを回避した
根本的な解決ではないが、動けばいい！(うわっ自分で言ってて恥ずかしい

**デフォルトの名無しさん** · 2020/05/01(金) 06:16:44.51

VScodeなのかdelveなのか、デバッガでスライスを見たとき64個までしか見えません
どこの設定を弄れば最後まで見せてもらえるのか、調べてみたけれど分かりません
→ githubのgo-delveとかvscode-goとか
このカスタマイズについて情報があれば教えてください