Conversation

Notices

1. らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 21:40:54 JST らりお・ザ・何らかの🈗然㊌ソムリエ

   別の型にすると、それはそれで今度は相互の型変換を無限に実装する破目になったりするので、それが工学的に正しいかというのも怪しい場合がある

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 21:42:53 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     std::ffi::OsStr - Rusthttps://doc.rust-lang.org/stable/std/ffi/struct.OsStr.html#trait-implementations

     たとえば str, Path, OsStr (とそれぞれの owned な型) だけでもこんなに PartialEq やら何やらが発生することになるわけで……

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 21:43:11 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     あるいは to と cc と bcc みたいな本質的に対等な型をどこまで一緒にするか、あるいは本質的に対等でないが自明に互換性のある型をどこまで一緒にするか、みたいなデザインの判断も悩ましいところ

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 21:48:44 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     • 杉田匠

     @tacumi 微妙ですね (受信者からすると同じですが送信者からすると taint flag の有無くらいの意味の違いはある)

   • 杉田匠 (tacumi@misskey.io)'s status on Sunday, 16-Aug-2020 21:48:45 JST 杉田匠

     in reply to

     @lo48576@mastodon.cardina1.red toとccは本質的に同じと見えるけどbccって同じなの?

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 21:59:02 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     • 杉田匠

     @tacumi 受信側ではそもそも自分が to か bcc かを区別する必要がないというのと、 bcc にあった項目を to に移動する際に一切破綻が起きないという点に、同質性を見出していました

     taint flag のようなものというのはもうちょっと正確にいうと information flow typing みたいな話で、「型に対して『これは公開されて良い』とか『これは洩れては困る』などの属性を与えてやることで型検査時に情報漏洩の可能性を検出しよう」みたいなテクニックが to / cc と bcc に適用可能なので、その点では差を付けることができるかなと。ただ、これはデータとしては同じ構造と意味を持つが利用方法や出自が異なる、というような解釈ができるので、型に異なる属性を付けられるからといって全くの別物であると称するのはちょっと主張が強すぎるかなと思っていました

   • 杉田匠 (tacumi@misskey.io)'s status on Sunday, 16-Aug-2020 21:59:03 JST 杉田匠

     in reply to

     @lo48576@mastodon.cardina1.red bccは送信された側が他のbccを見えないという設定になってるから明らかに違うと思うのだけどtoとbccがほんとにわからない。taint flagというのは対象になってるかどうかのフラグってこと?

   • 杉田匠 (tacumi@misskey.io)'s status on Sunday, 16-Aug-2020 22:05:10 JST 杉田匠

     in reply to

     @lo48576@mastodon.cardina1.red 型というのはそういうものを含めて計算可能にするものだと思っていたので、無意味だとしても公開性の変更のために一つ変換を噛ませるのがいいかと思いました。確かに送信対象という処理から見れば同じものなのですが、それだったらわざわざ分割する必要がないのです。先人が分割するならそれ相応の意味があるはずで、我々はそれを汲み取ってできる限り明文化して自動化すべきなのです。

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 22:05:10 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     • 杉田匠

     @tacumi もちろん私も思想としては用途まで含めて型を分けろマン寄りです。しかし、たとえば ActivityStreams や他の莫大な語彙を持つような規格のような、型が増えすぎることで開発者にとってネガティブな影響が大きくなる場合がありえるので、そのとき何かしらの「同一化」により型を減らす必要が実用上生じるのかなという文脈でした。その場合、 to / cc / bto / bcc は「同一化」の候補に真っ先に上がるかなと。

   • 杉田匠 (tacumi@misskey.io)'s status on Sunday, 16-Aug-2020 22:11:31 JST 杉田匠

     in reply to

     @lo48576@mastodon.cardina1.red 処理の同一化のためであればスーパークラスを作ってその送信処理を任せて、cc,bcc,btoの個別のtoString(),println()のようなものを作成するのがオブジェクト指向としては最適かなぁ……

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 22:11:31 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     • 杉田匠

     @tacumi 継承は人類を不幸にするという信仰を持っているので……

   • 杉田匠 (tacumi@misskey.io)'s status on Sunday, 16-Aug-2020 22:14:56 JST 杉田匠

     in reply to

     @lo48576@mastodon.cardina1.red 同一のものとして見るには継承するかインタフェース実装するか、抽象化を極端にしてプログラムと人間の意思を別々にするしかないんだよ

   • らりお・ザ・何らかの🈗然㊌ソムリエ (lo48576@mastodon.cardina1.red)'s status on Sunday, 16-Aug-2020 22:14:56 JST らりお・ザ・何らかの🈗然㊌ソムリエ

     in reply to

     • 杉田匠

     @tacumi 結局「つよい型システムが欲しい」に帰着するし、つよい型システムは永遠に型検査が終わらないので、世界の限界のそばでダンスし続けるしかないんですね