ていうか、点字ブロックだけじゃなく消火栓やAEDの設置なんかも含めて、公共空間の安全に関するデザインの場面におけるデザインをデコレーションと勘違いしてる馬鹿ども(事業者や、設計者がわかる場合は設計者個人)のブラックリストみたいなの作ったら啓蒙になりそう＞＜
書いた＞＜
形状も色もダメ (#.4428959) | 点字ブロックに隠れアンパンマンの仕掛け、視覚障害者から危険と指摘で交換へ | スラド https://srad.jp/comment/4428959
2023年3月15日
走行距離100万キロ 走ってみたらどうなった？ | NHK | ビジネス特集 https://www3.nhk.or.jp/news/html/20230315/k10014007831000.html
昨日の配信の1:34:00辺りとか、空の具合とか的にもかなりWindows XP＞＜
"BigRigTravels LIVE | Lebec to Sacramento, CA (3/16/23 11:24 AM)" を YouTube で見る https://www.youtube.com/live/sxTunnRsxX0?feature=share
イリノイのおじいさん、昨日からカリフォルニアのセントラルバレーを走ってるけど、3月のセントラルバレーってあちこちがわりとWindows XPっぽい＞＜
"BigRigTravels LIVE from Sacramento, California. ( Mar 17, 7:06 AM )" を YouTube で見る https://www.youtube.com/live/uKuQj2ZpWXo?feature=share
orange
さんがブースト
そりゃまあ != を重めにユーザ定義しない人には関係ない話だろうけど
orange
さんがブースト
まあ言語仕様なんてだいたいは「今更後知恵で言われても」ばかりなのでそういうものだろうけど、それは妥協する理由ではあっても減点しない理由ではないので……
オレンジ的には演算子のオーバーロード大好きだし、出来ることならAdaのように標準の型はなるべく使わない思想で書きたい(C# では無理だけど)し、Delphiでも部分範囲型とか色々多用してたし、実際に必要な場面があるか謎だけど、nullとの比較で特殊な処理をするクラスも、オレンジ的には書ける言語の方が望ましいと感じる＞＜
Adaのように積極的に型システムに頼って静的型検査で安全を確保するって考えを達成するのに必要な範囲であれば、型システムに柔軟性が必要かもって＞＜
orange
さんがブースト
まああとオマケで、 ! 演算子が前置と後置の両方で使えるのも x !is not null (本当は x! is not null 相当の解釈をされている) の勘違いが通ってしまう原因なので、そこは記号を変えるなりすべきで前置/後置演算子両方あり (しかも意味は全然違う) みたいな割当は避けるべきだった
その変な書き方自体その記事ではじめて知ったし、オレンジは古いバージョンのC# で書いてるので使えない書き方かもしれない＞＜
でもどっちにしてもオレンジは
if (hoge!=null) { なんか処理 }
みたいな書き方しかしないから、別にいい＞＜(？)
orange
さんがブースト
あー、もしかして early return する if の場合は後続コード全てが暗黙に else 節に入っているというセマンティクスになってる？
なら理解はできるけど、名前の導入くらい重要なことはちゃんと専用の文法を用意しなよと思うわ
orange
さんがブースト
ところが最後のコード例を見ると残るっぽい書き方になってる
orange
さんがブースト
これはさすがに x は残らないはず
orange
さんがブースト
たとえば C++ でも if(auto x = hoge) {...} における x のスコープは then 節と else 節の中で済んでいるはずで、「if の条件の形で if 外から参照可能な名前を宣言/定義する」というのは妙じゃないですか？
orange
さんがブースト
で、次に妙なのが、バインドを伴うパターンマッチと boolean の式としての条件式が同じ書き方をできて、しかもそのバインドのスコープが if を抜けた箇所まで残ってる部分。
if (a.X is not { } x) return;
の後ろまで x が残るのは普通にうわぁとなります (ブロックスコープのない Python かよ……)
orange
さんがブースト
うわぁポイントはいくつかあって、一番根本的で今更どうしようもないのは変数が透過的に参照になっているところで、アドレスと値を明示的に区別できる言語仕様なら「ポインタと null を比較」は「ポインタの参照先の値をユーザ定義の比較演算子で比較」と混同しようがなかった。
透過的な参照は他にも shallow copy と deep copy の問題とか引数渡しと書き換えの問題とかを発生させる悪しき概念だと思う。
Rubyを例に出したのはこれを参考にした＞＜
"Ruby: それはstdlibに搭載されているモジュールをrequireすると、整数割り算の動き方に影響を与えてしまう言語。"
Rubyにはウンザリ！動的型付け、副作用、およびオブジェクト指向プログラミング全般からの考察 | POSTD https://postd.cc/sick-of-ruby-dynamic-typing-side-effects-object-oriented-programming/
よく知らんけどRubyみたいに既存のクラスの振る舞いさえ変わっちゃう言語(？ よくわからん)ならあれだけど、新たな数値型を実装したりする場面とかで演算子のオーバーロードを使って、そのなかでの演算子を使う処理が重いかもしれないって、文句あるならそういうの使わずに組み込み型使うとかすりゃいいじゃん＞＜
型安全の考えに対して逆行してると思うけど＞＜
どの部分が「うわぁ」なのかよくわからない＞＜；
(==でいいじゃんって思うし重いかもしれないって重い判定が必要な場合には重くなるの当たり前じゃん感だし、==演算子のオーバーロードをしてある何らかのクラスの当該処理がnull比較でも重いのであれば、そのクラスの問題(そのクラスを書いた人の責任)でしょ？＞＜
それをやめれって制限かけてったらJavaみたいな、ちょっとオリジナルの数値型を作ろうとするだけで演算子が使えなくなる柔軟性の無い言語に行き着いちゃう＞＜)
- ＠orange_in_space
2017年 4月に登録
