X
次世代言語9[Haskell Rust Kotlin TypeScript Dart]
■ このスレッドは過去ログ倉庫に格納されています
0101デフォルトの名無しさん
垢版 |
2018/03/08(木) 21:38:40.38ID:EsrBfKCX
>>100
「例外を無くした。あれは大域ジャンプだ。行き先の見えないgotoだ。
　フローが無茶苦茶になる、複数の戻り値返すから各自チェックするように。
　複数の戻り値返せるからマジックナンバーとか返すなよ」
なんて、割り切りというより考え抜いたであろう仕様も、結構叩く人は叩くしな。

ジェネリクス的なものはどうなるんだろう。
正直型でのswitchでだいたい事足りてるし。
0103デフォルトの名無しさん
垢版 |
2018/03/08(木) 21:52:55.87ID:EsrBfKCX
>>102
何で？
コンパイルする時に誤りに気づかないとかそういう話？
void*が渡せるよりも、interface{}は実際には型持ってるからよほどマシな気が。
ジェネリクスしたらすごい数の関数が作られうるし、使い方の問題な気がするけどな。
そもそも継承という概念が希薄だから、ジェネリクスにしても幸せになれないと言うか、明示的に何らかのinterfaceを渡す方がマシだと思う。
Writer受ける関数みたいに。
0104デフォルトの名無しさん
垢版 |
2018/03/08(木) 22:31:36.69ID:to5KOUcv
>>103
実行時に解決するのは極力避けたい。
防衛的プログラミングをしたい。
AST系ライブラリを使いこなせるようになってコード生成でもいいけど。
0106デフォルトの名無しさん
垢版 |
2018/03/08(木) 22:37:10.68ID:bpZjqWPW
例えば今、任意のオブジェクトを格納できるコンテナ
（二分木でもハッシュマップでもブルームフィルタでも）
のライブラリを作りたいとしよう

このライブラリに、初期化時に任意の型しか格納できないようにする
まあつまりJavaのList<T>みたいなことをしたいと考えたときに
Goでは型ごとにラッパをつくって実行時に動的にチェックする以外に実現方法がない

これをコンパイル時にチェックしたいという要望は自然と思うが？
0107デフォルトの名無しさん
垢版 |
2018/03/08(木) 22:46:42.29ID:bpZjqWPW
つか自分で言ってて思ったがこれinterface{}が悪いとかじゃなくて
単純に高階型が欲しいってだけの話だわ
0108デフォルトの名無しさん
垢版 |
2018/03/08(木) 22:51:14.55ID:to5KOUcv
>>105
それもあるけどライブラリを提供するときに引数がinterface{}だとドキュメントに説明がいるでしょ。そういうのが嫌。
0109デフォルトの名無しさん
垢版 |
2018/03/08(木) 23:04:06.14ID:y3Zn8R8X
コンパイルが遅くなるので人間が出来る事は人間がやってください
0110デフォルトの名無しさん
垢版 |
2018/03/08(木) 23:05:42.03ID:Qr0iRnUQ
>>108
どっちにしろ実行時に起こる現象は説明が必要だろ。
確かに動的だったりテンプレートみたいなもんだと読むのきついなと思うことがあるけど
型で述べられる記述力なんてコード量の割にそんなに豊かなもんでもない。
俺は優良なドキュメトとテストコードのが上回ると思ってる。
goのinterfaceと比べて継承の方が入力の範囲を特定する能力は高まるけど、
同時に型情報をどっさりコンパイラと人間に読ませることになるわけだ。
割にあってると思わない。
0112デフォルトの名無しさん
垢版 |
2018/03/08(木) 23:12:19.99ID:bpZjqWPW
>>110
Scalaとか見てると気持ちはすごくわかる
しかしせめてコンテナ型くらいは型制約欲しいという気持ちもわかってくれ
0115デフォルトの名無しさん
垢版 |
2018/03/09(金) 00:49:56.76ID:cqMSJuy/
>>110
ちょっと具体例が浮かばなくて適当な説明になるけど
ある引数に io.Reader もしくは io.Writer だけが来て欲しいって場合に
interface{}で一旦受け入れてどっちかじゃなかったらエラーって書くのがしんどいの。
引数にio.Reader | io.Writerって書けるようになれば
どっちかしか来ないことが保証されるからエラーハンドリングのコードが減る。

別に型システムがほしいとかじゃなくて
なんでも受け入れるinterface{}にしてしまう状況を避けたい。
0116デフォルトの名無しさん
垢版 |
2018/03/09(金) 04:10:38.55ID:4sIM9IpC
R | W より Or<R, W> が良い
記号を使うと記号アンチがうるさいし、継承と総称型を混同するやつもうるさい
0117デフォルトの名無しさん
垢版 |
2018/03/09(金) 07:28:22.67ID:zhxSKG5B
その場合 `Or<A, Or<B, C>>` と `Or<Or<A, B>, C>` の等価性どうする?って話しになるけどね
0120デフォルトの名無しさん
垢版 |
2018/03/09(金) 09:19:07.89ID:Nb7UaI4p
せめてパターンマッチくらいは入らんかなあ
型判定のためにifをダラダラ並べるようなコードなんて誰も嬉しく無いよ
:=もあるんだし構文糖衣まで全て拒否してる訳でも無いだろうに
0121デフォルトの名無しさん
垢版 |
2018/03/09(金) 10:34:44.49ID:cqMSJuy/
>>118
まぁ例えばだから。もっとぴったり来る例を示せればよかったんだけどね。
関数のオーバーロードも合わせて欲しいな。関数名考えるのがしんどい
0124デフォルトの名無しさん
垢版 |
2018/03/09(金) 12:12:54.21ID:sqnwGWQK
>>110
ドキュメントが常に最新の状態であることを静的に
保証する方法がない限りは静的型付けの型情報の方が信頼できる
腐ったドキュメントほど有害なものはない

腐らせるヤツが悪いとか言われそうだが
腐らせるのは自分ではなく同じチーム内の誰かだ
他人よりコンパイラの方が信頼できる
0125デフォルトの名無しさん
垢版 |
2018/03/09(金) 12:43:31.33ID:kL3iaTSl
interface{}を他の言語のobjectみたいなほんとに雑な受け方と一緒にしないでくれよ…。
実際に書いたら、結構使う場面が限られて来ることもわかるだろ…。

>>121
オーバーロードの禁止ははまあ必要悪だと思う。
型同士に階層が無いので、2種類のinterfaceを受ける関数があったとき、その2つともを実装している型に対して関数が定まらんのでは？
0126デフォルトの名無しさん
垢版 |
2018/03/09(金) 12:56:29.64ID:7FF0Q/q6
>>125
してねえよ
コンパイル時の型制約を足したいって話で、機能的にinterface{}への switch t.(type) で十分なのは承知の上

ifが並ぶっていってる奴はたぶんswitchで型判定できるの知らない気がする
0127デフォルトの名無しさん
垢版 |
2018/03/09(金) 13:27:20.95ID:RwDfRr6t
仮にGoにジェネリクスを実装するとしたらどこまで必要になるんだろ
共変性と反変性は必要？
部分適用は必要？
C++のメンバ型みたいなのは必要？
0130デフォルトの名無しさん
垢版 |
2018/03/09(金) 16:38:15.55ID:kL3iaTSl
>>129
渡されたものをどう解釈するかの余地が他の言語と結構違う
たとえば、
type xxx struct {}
func (x xxx) foo(){}
func (x xxx) bar(){}
type Ixxx interface {
foo()
}
func (ix Ixxx) bar(){}

があったときに、interface{}で受けたものをアサーションでxxxとすると、xxxのbarが、
アサーションでIxxxとすると、Ixxxのbarが呼ばれる。
あくまで、すべての構造体はinterface{}を満たしているだけで、実際には型を持ってるし、
interface{}とIxxx{}も満たす範囲が違うだけで上位下位ではないし、構造体の型とも違うのでレシーバは別になる。
interface{}から派生したものではないって感じ。
0131デフォルトの名無しさん
垢版 |
2018/03/09(金) 17:07:33.29ID:4sIM9IpC
もしかしてswitchに型チェック機能追加したやつが戦犯かな
ただのVisitorパターンならジェネリクス対応は難しくなかった
0132デフォルトの名無しさん
垢版 |
2018/03/09(金) 18:13:47.78ID:kL3iaTSl
型チェックでswitchとジェネリクスは全く関係ない。
オーバーロードと同じく、何として処理するかと、その型が何か、に関して曖昧性を排除してるから。
暗黙のキャストも無いでしょ。
戦犯呼ばわりはどうかと思う。他の言語に毒されすぎ。
0133デフォルトの名無しさん
垢版 |
2018/03/09(金) 19:09:25.15ID:kljWqerj
Goにオーバーロード無いの批判される事あるけど
HaskellやRustだって型クラスやトレイトを使わないとオーバーロードできないし
TypeScriptも型が多重定義できるだけで実体は一つだし
むしろ最近の言語はC++みたいな単純なオーバーロード付けないのがトレンドな気がする
0135デフォルトの名無しさん
垢版 |
2018/03/09(金) 20:41:59.05ID:lMH5BOjd
>>124
ドキュメントよりコンパイラのが信用できるかも知れんが
それ以上にテストコードの実際の動作のが信用できるよ。
c++まともに開発に使ってた奴ならどれほどコンパイラだよりが危ういかわかると思うけどね。
0137デフォルトの名無しさん
垢版 |
2018/03/09(金) 21:48:54.86ID:OETiniYx
>>133
むしろオーバーロードと型推論を共存させたいというのが型クラスの最初の動機だったのでは
0138デフォルトの名無しさん
垢版 |
2018/03/09(金) 21:50:23.61ID:sqnwGWQK
>>135
そりゃテストコードが全てのコードに対して書かれていたらの話で
実際にはテストカバレッジ100%なんてあまり現実的な数値じゃない
GUIの場合はテストを書くこと自体がなかなか難しいし、他にも仕様が変わりやすいような
部分は変わるたびにテストも書き直すんじゃ、コストが割に合わないこともある
それらを考慮して、あえてテストを書かないという選択をすることも充分あり得る
静的型付けならテストが書かれていない部分でも型情報からある程度ならチェックが出来る
動的型付けはテストがなければ何もチェックできない

テストを書かない奴はバカみたいな言い分はあまり好きじゃない
テストカバレッジ100%を目指す奴のほうがよっぽどバカだと思う
0139デフォルトの名無しさん
垢版 |
2018/03/09(金) 22:24:57.88ID:mOP6pgpS
C++の型安全とHaskellの型安全って随分違うでしょ
理論がしっかりしてて型システムが豊かな方が型安全で提供される品質は高い
Haskellは「コンパイルが通れば大体想定通りに動く」って言われる程度には型を信じれるよ

これが行き過ぎるとIdrisやCoqみたいに「実行できれば仕様を満たしている」みたいな開発もできる
ハードル高いし実用できるほど簡単じゃないからまだ何個かブレークスルーが要るがね
0140デフォルトの名無しさん
垢版 |
2018/03/09(金) 22:28:04.16ID:5gZ3T8dE
>>130
残念ながら他言語のobject型とinterface{}の違いがこの説明ではよくわからん。

あんさんは他の言語のobject型を雑な受け方と評したんだぜ。具体的にこの説明では、
なるほど他の言語のobject型で値を受け取るのは雑な受け方だった。って納得しない。
どのへんが雑じゃなくなってるわけ？
0141デフォルトの名無しさん
垢版 |
2018/03/09(金) 22:30:56.35ID:5gZ3T8dE
>>138
qiitaの記事でだいたいカバレッジが85%位が理想値でそれを超えるとしんどくなるだけで意味ないってのは見たな。
0142デフォルトの名無しさん
垢版 |
2018/03/10(土) 09:17:00.38ID:iLIqn+zB
>>135
C++のコンパイラに頼るのは危ないってのはテンプレートがダックタイピングだからじゃないの？
だとしたら、それは単にC++のテンプレートの仕様がクソってだけの話で
C++のコンパイラがクソって言うのは筋違いだと思うんだけど…
それとも他に理由があるの？
0143デフォルトの名無しさん
垢版 |
2018/03/10(土) 09:30:50.15ID:iLIqn+zB
書いた後で思ったけど、
C++のテンプレートってダックタイピングって言われてるけど
きちんとコンパイルエラーになったような…？
使ってたの3年以上前だから忘れた。どうだったっけ？
0144デフォルトの名無しさん
垢版 |
2018/03/10(土) 09:57:39.05ID:X26PuUpn
たぶん135は、コンパイラがバグってて出力される機械語が怪しいという話をしてる
別にC++に限った話ではないんだけど昔は結構多かった
0145デフォルトの名無しさん
垢版 |
2018/03/10(土) 10:03:15.55ID:V+AonR8i
>>140
うーん。なんにでもなれるスーパークラスで受けてるんじゃなくて、何もかもを満たすインターフェイスで受けてる。
クラスというか構造体同士に階層も無いし、
インターフェイス同士にも無いから。
だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、
むしろどうキャストするか(何がほしいか)で、それに合わせたレシーバを呼んだりできる。
0147デフォルトの名無しさん
垢版 |
2018/03/10(土) 10:47:28.09ID:wavGSJ3d
普通は型の階層を利用したキャストの方が丁寧で
Goのような要件さえ満たせばなんでもキャストできる方が雑なんだけどな
雑なGoに丁寧なジェネリクスは似合わないって話の方がしっくりくる
0148デフォルトの名無しさん
垢版 |
2018/03/10(土) 11:47:59.83ID:BpWzRYHd
動的型は丁寧なコードも雑なコードも書けるよ
静的型のキャストは雑なコードだけを集めて濃縮したような存在
0149デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:02:58.66ID:vrfy4Usj
型の階層ってのからまず脱却した方が良いところだと思うけどね。
型の階層の横紙破りとしてインターフェイスを作ってさらにインターフェイスも階層を持つとか、goやり始めてから悪手な気がしてきた。
他の言語もmixinとかtraitなんかで色々やってるけど、そういう方向で対応すべきもんなんだと思うよ。俺は。

rubyのようにobjectの親を作る羽目になったり、どのみち破綻する。
型の継承による、と言うが、型の継承に頼ったキャストとしか言いようが無いんでは？
0150デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:03:37.10ID:ysTMLqRd
>>145
>だから、他の言語でObjectからキャストし直すときに、キャスト先の階層構造を考えなくてもいいし、

どういうこと？Object型は大抵すべてのインスタンスの親のはずでは？
一度Object型の変数に突っ込んだなら、それってもう実質、動的言語的扱いになるから人間側が元の型を意識しなきゃいけない。
これはGoでもおんなじでしょ？

あと以下は正直どうでもいい話なんだけど敢えて突っ込む。

Goのインターフェースは階層構造を持たないって言ってるけど
も結局用語の違いってだけで実質階層構造みたいなのはあるでしょ。
Io.ReadWriter は io.Writerを内包している
io.Writerはからインターフェースを内包している

Io.ReadWriter => io.Writer => interface{}

他の言語は階層構造を明示しているけどGoの場合はそれがコンパイラによって自動化されているってだけでは?
もちろん自動化されているってのはありがたいけどね。
0152デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:13:23.90ID:ysTMLqRd
>>148
動的型のキャストと静的型のキャストに違いがあるとは思えないけどなぁ。
俺の考え方はこう。
動的型: 人間側で型の追跡を頑張る
静的型: コンバイラ側に型の追跡を任せる。ただしobject型とかに渡すことで人間側で頑張ることもできる。

動的型は基本雑なコードだらけ。人間側が型を決め打ちしてメソッドを実行しないとやってられない。
だって毎回instanceof とかで型をチェックしてからメソッドの実行とかしてないでしょ？
0154デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:24:33.09ID:bKdAMFdx
>>150
そんなことないよ。例えばtoStringみたいな、親から生えてるメソッドは、objectのまま呼べて、しかもインスタンスのメソッドが呼べるでしょ。
goはそうはなってないの。インターフェイスをレシーバとする関数が呼ばれる。

内包してないよ。
ReaderはReadを
WriterはWriteを
ReaderWriterはReadとWriteを実装しているインターフェイスなだけ。別のインターフェイス。そこに上位下位は無い。

階層構造が暗黙に決まってるんではなくて、そもそも階層構造を持ってない。
0155デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:35:41.84ID:9xaE30s9
なんでもできる c++ で書くなら
なんのメンバーも持たない class interface の直接の
派生型として色んなインタフェースがあるようなもんか

COM に似てるな、というか COM のインタフェースの概念の焼き直しか。
0156デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:36:05.42ID:X26PuUpn
ダックタイピングとnominalな階層型の違いを言葉を変えて繰り返しているだけで
問題のinterface{}がobjectより良いという説明にはなってないな
0157デフォルトの名無しさん
垢版 |
2018/03/10(土) 12:42:10.90ID:jPHJ8KIe
>>138
別に全部のコードにテスト書けとは思わんが
それでもそこまで引数の型がどうなのか気になるインターフェイスなら
テストコード書けよ。

てかそこまで作業が圧迫してるなら型をガッチガチにやる言語のが
調整する手間考えた場合割に合わんだろ。
0158デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:01:42.42ID:iLIqn+zB
>>157
どの程度なら「気になる」のかってところに認識の違いがありそうだな
静的型派の人間は全てコードの型情報が気になっちゃうんじゃない？
少なくとも俺は全ての引数の型が気になってしまうタイプの人間だよ
0159デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:02:25.28ID:BpWzRYHd
>>152
動的型のコードは二種類に分けられる
静的型で丁寧に書いてから型を省略したようなコードと
静的型で雑に書いてから型を省略したようなコードだ
0160デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:10:46.65ID:wavGSJ3d
「階層を持つから安全にキャストできる」と「安全にキャストできるから階層を持つ」がごっちゃになってる人がいる
0161デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:12:51.16ID:jPHJ8KIe
>>158
まあ極論すれば感覚的な話だしね。
感覚として型を気にして助かることなんて 5 % くらいじゃないかと思ってる。
対してテストがある場合は 40~50%くらい助かる。
準備するコストとして型が 10~20 としたらテストは 30~40 といった印象。

なんで個人的にはそこまで型を整備するよりかはテストに時間使った方がいいと考えてる。
まあ抽象論一発で済めば嬉しいって気持ちはわかるんだが
実際そうはならんからね。。
0162デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:17:24.66ID:V+AonR8i
>>156
端的に言えば、スーパークラス(と言う概念もないが)にキャストしてして渡してない、as-isで渡してると言うところが違うし大きい。
良いとも言ってないぞ。
違うし混同するなと言ってる。
Objectに相当するものが無いので、良いも何も比較対象ではない。
0163デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:21:00.62ID:CNpckm4H
スーパークラスにキャストねえ。
どの言語でもその場合は as-is で渡るだろう
0165デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:24:20.18ID:V+AonR8i
as-isで渡るは確かに語弊があったな。
別の型のオブジェクトやインターフェイスとして渡されてるんじゃなくて、って感じ。
0166デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:27:51.68ID:X26PuUpn
>>162
>>125でobjectを雑と評したからには当然interface{}の方が良いという主張と思ってたんだが
実際の詳細は別にしてあなたの説明では聞けば聞くほど同じとしか思えない
俺じゃないが>>155なんかCOM的な構造で代替可能という理解をしてるし
0167デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:31:43.54ID:CNpckm4H
とはいえ言いたいことはわかる
オブジェクトに似ているがオブジェクトを渡しているわけではない、
オブジェクトとそれの持つインタフェースは1対多

COM のインタフェースや多重継承を用いた場合のC++に似ている
特に前者とはほぼ完全に同じものだ
インタフェース抽象って奴だね

この場合実行モデルとしてはインタフェースに階層関係は要らなくなる
複数のインタフェースを持つことから(派生による差分宣言、差分実装ではなく)
ミックスインが基本となるから。
0168デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:31:58.31ID:BpWzRYHd
as-is型に実装を合わせるテンプレート
as-is実装に型を合わせるキャスト
これが次世代の争い
動的型は次世代ではないから政治的中立
0169デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:52:58.58ID:V+AonR8i
>>166
同じではないでしょ。
COM的な構造で代替可能ってのは、>>166自身は理解してるの？理解してたらそのレスにはならんと思うけど。
そもそもが思い込みで人の発言に「良い」を勝手に補完してなんでそんなにしつこく食いついてくるかわからん。
理解が足りなくて同じだとしか思えないなら開き直らないでほしいわ。
0170デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:54:45.25ID:ysTMLqRd
>>154
だから階層構造がないのはわかってるつーの。実際的な違いがないっていってるの。
実質Object型 とinterface{} はおんなじ扱いにしかならない。
Object型にはtoStringがあるけどinterface{}にはない？ 別にそんなのはどうでもいい話。

interface{} に値を突っ込むと人間側が型を意識する必要がある。
動的言語的な扱いになっちゃう。

この点においてObject側と一緒だよね。

ここが最大の肝であり、「Object型でうけるのは雑」っていってるのはこの部分に差があると期待して質問したのに、
そこに関しては違いを見出していない。
なら雑な理由って何よ。
0171デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:55:30.73ID:wavGSJ3d
今気が付いたが>>145の言ってることは根本的に間違ってる
>>130みたいなインターフェイスのレシーバはそもそもコンパイル通らない
つまりどの型にキャストしても同じレシーバが呼ばれることが保証されてる
そこがGoの型は階層を持たないという根拠になってたはず
エアプは黙ってろ
0172デフォルトの名無しさん
垢版 |
2018/03/10(土) 13:57:07.23ID:X26PuUpn
>>169
IUnknownが便利に使われてるのと
QueryInterfaceの実装次第でメンバーに飛ばすこともできるのが似てるって話だろ
COMは実装側が応答する型(GUID)を決めないといけなくてダックタイピングにはならんから
俺は必ずしも似てるとは言わんけど、あなたの説明はそう思われてもしょうがないってことだ
0173デフォルトの名無しさん
垢版 |
2018/03/10(土) 14:21:55.45ID:BpWzRYHd
classの多重継承ができる言語ならinterfaceはclassの構文糖ということにできた
多重継承を制限したことでinterfaceとclassの互換性が非自明になった
0174デフォルトの名無しさん
垢版 |
2018/03/10(土) 14:23:37.99ID:V+AonR8i
>>171
これは例が悪かったか。
スマホで書いたからすまん。

ある型にアサーションした場合、アサーション先の型のレシーバが呼ばれるよ。
もとのレシーバではない。
0175デフォルトの名無しさん
垢版 |
2018/03/10(土) 14:26:15.83ID:V+AonR8i
>>170
おんなじ扱いをすれば同じになるだろうな。
扱い方の余地の問題なんだが。

人間側が型を意識する必要がある、この点に於いてObjectと同じと言うのは雑すぎる。
動的言語的扱い方と言うか、jsonのUnmarshalなんか見た方が多分わかりやすいと思う。俺が言ってることは。
0177デフォルトの名無しさん
垢版 |
2018/03/10(土) 14:31:49.68ID:V+AonR8i
interface{}で受ける関数を呼ぶときは、
とりあえず、スーパークラスのObjectに(暗黙的に)キャストして渡してるのではなくて、あるインターフェイスを実装している型として渡してる。
全クラスがIfooをimplementsしている状態で、Ifooを受けているだけ。
そこにキャストは発生してないし、だから、キャストではなくアサーションで型を判定するだけで(キャスト無しで)中身の型が分かる。
その時に、もとの構造体ではなく、あるインターフェイスとしてアサーションする事ももちろんできる。

そこだけでも伝わってほしい。
0180デフォルトの名無しさん
垢版 |
2018/03/10(土) 14:56:06.20ID:ysTMLqRd
>>175
それって結局reflectバッケージを見ろってこと？
>>177
型キャストが雑ってこと？
型アサーションだと型が合わないとerrorを返すから雑じゃないってこと？
0182デフォルトの名無しさん
垢版 |
2018/03/10(土) 15:26:15.03ID:Uh7G7RUR
>>180
アサーションが丁寧というのは語弊があるが、インターフェイスからのアサーションはそもそも本来の型自体も持ってるのでキャストしているわけではなく、assert、言明し直してるだけで、別の型として一度も扱わない。
0183デフォルトの名無しさん
垢版 |
2018/03/10(土) 15:28:33.49ID:wavGSJ3d
>>174
アサーションでもレシーバが変わることはない
自分で試したことないから分からないんだろ
>>177のキャスト無しで渡してるってのも間違いで実際はキャストされてる
キャスト無しで渡してたらそれはジェネリクスだ
たぶん>>177はポインタや参照を理解してなくてキャストの意味をはき違えてる
objectにキャストしたら静的オブジェクトが動的オブジェクトに変換されると思い込んでるようにしか見えない
0184デフォルトの名無しさん
垢版 |
2018/03/10(土) 15:39:34.50ID:Uh7G7RUR
>>183
あることあるから、レシーバが変わる事知ってるんだよ。
そうじゃない。履き違えてないよ。
ジェネリクスはもっとちがう。コンパイル時に関数自体が型ごとに分かれるのが俺が言うジェネリクスとオーバーロード。
オブジェクト指向脳でわけわからん事言わないで。
0185デフォルトの名無しさん
垢版 |
2018/03/10(土) 15:56:33.06ID:ysTMLqRd
>>184
が、言いたいことを整理すると
Go言語のinterface{}は他言語のObject型とは違う。
なぜならGo言語のinterface{}型は内部的には型情報を保持しており
reflectバッケージを使うことでいつでも元の型情報を取得できるから
ってことでOK?

これって逆に言うと他言語のObject型は内部的に元の型情報を保持しないの？
0186デフォルトの名無しさん
垢版 |
2018/03/10(土) 16:04:38.45ID:X26PuUpn
本来のデータポインタはそのままで実行時型情報をペアにしてinterface{}(fat pointer)にしているのを
キャストしているしていない言い張ってるだけかな。まあ言葉はどっちでもいいが

ちなJavaタイプのnominalなinterfaceや多重継承はデータポインタに特定のオフセットを加減算する(ポインタの値が変わる)
場合がほとんどだが、fat pointer方式の実装も無いわけではない
0188デフォルトの名無しさん
垢版 |
2018/03/10(土) 17:37:00.44ID:Hgt7PccX
エアプ呼ばわりされて過剰反応するのが真のエアプ
エアプでないことを示すのが普通の人
0189デフォルトの名無しさん
垢版 |
2018/03/10(土) 17:37:33.50ID:Uh7G7RUR
>>185
内部的に持ってるが、クラス構造が階層型であるが故にObject型という型で扱われた上で、サブクラスにダウンキャストするじゃん？で、またアップキャストするかもしれん。
だからジェネリクスやオーバーロードだと共変なのか反変なのか、あるいは非変なのかが問題になるし、Javaなんかはジェネリクスは非変だけど、配列は共変みたいな事になってるし、c#なんかだと最近変性注釈できるようになったり、まだゴタゴタしてる。

ちなみに、interfaceへのアサーションはreflectとは違って、interface自体が型を持ってるので、reflectで型を判定したりメソッド呼ぶのとは結構な差がある。
古いけどこのへんか。
https://research.swtch.com/interfaces
0191デフォルトの名無しさん
垢版 |
2018/03/10(土) 17:47:29.26ID:NO/eROxb
エアプなんか使ったって、レッテル貼るだけで議論ができないようにしか見えないんだからやめときなって
0195デフォルトの名無しさん
垢版 |
2018/03/10(土) 18:20:49.51ID:ysTMLqRd
例えば
func ToString(any interface{}) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
return "???"
}

上記コードはこうできるようにして欲しい

func ToString(any (Stringer | int | float)) string {
if v, ok := any.(Stringer); ok {
return v.String()
}
switch v := any.(type) {
case int:
return strconv.Itoa(v)
case float:
return strconv.Ftoa(v, 'g', -1)
}
}

引数にinterface{} があるのはやっぱりJavaとかで引数にObject型が来るのと同義だと思うわ。
0197デフォルトの名無しさん
垢版 |
2018/03/10(土) 19:46:35.03ID:YxlaXMRK
結局Objectの方がinterface{}より保証されてるものが多いから、雑なのはinterface{}の方じゃーん
0199デフォルトの名無しさん
垢版 |
2018/03/10(土) 22:06:56.73ID:V+AonR8i
>>197
保証されてるものが多いんじゃないよ。
保証されるべきでない関連性を持ってないものも、関連性を持っているかのごとく扱われるんだよ。
0200デフォルトの名無しさん
垢版 |
2018/03/10(土) 22:10:01.27ID:V+AonR8i
自分が知らないものをたったひとつソースから「言い間違えなのか？」と言うのはどうかしてると思うわ。
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況