TypeScript part3

1 ：デフォルトの名無しさん：2018/04/26(木) 21:48:23.07 ID:mMDBzDaB.net

http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/

972 ：デフォルトの名無しさん：2021/12/30(木) 19:25:44.57 ID:zuTar3e4.net

言語仕様を変えるべきなんだろうな
typeで宣言した変数への代入は実行時に型チェック付きのマッピングにトランスレートすべき
ついでに言うとtypeで未定義の属性はマッピングするときにundefinedにすべき
これだけでTypeScriptによくある馬鹿馬鹿しいバグがかなり減るはずだ

type Foo {
x: string;
y: number; }

const foo: Foo = { y: “s” } as any
これはコンパイル時には無視していいが実行時にはエラーになるべきだし

const foo2: Foo = { x: “a”, y: 100, z: “111” }
これはzは消えるべき

973 ：デフォルトの名無しさん：2021/12/30(木) 19:33:44.30 ID:18t9WvJQ.net

>>972
いやそれはそのコードがバカじゃん……

974 ：デフォルトの名無しさん：2021/12/30(木) 19:34:37.32 ID:zuTar3e4.net

Javaは最も優れた設計でそもそもanyみたいな言語仕様がない
Objectは定義できるが暗黙のキャストでスルッと行くなんてことはあり得ないし無理やりキャストしたって実行時に必ず例外が飛ぶ
C#はanyに近いものでdynamicというのがあるがこれも誤ったキャストには実行時に例外が飛ぶ
どちらも型が嘘をつかないように言語基盤がしっかり担保してくれるから型を信用していい
当たり前のことを当たり前にやってくれる堅実な言語だ

975 ：デフォルトの名無しさん：2021/12/30(木) 19:36:08.35 ID:zuTar3e4.net

>>973
このコードは説明のためのスニペットだ
現実的にこんなコード書くわけないだろ
現実的には先に挙げたような状況でanyと戦わなければならない

976 ：デフォルトの名無しさん：2021/12/30(木) 19:44:03.93 ID:18t9WvJQ.net

>>971
>>975
なんの為のバリデーションとタイプガードだよ。
どこで間違った型が入りうるかなんか普通把握できるでしょうに

977 ：デフォルトの名無しさん：2021/12/30(木) 19:48:28.03 ID:pcTvcAXH.net

Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ
構造的部分型も便利だしany型なんて使うときには型ガードするよね
型に関してはJavaより好きだわ

978 ：デフォルトの名無しさん：2021/12/30(木) 19:51:25.70 ID:HvA/IBjD.net

Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと信用できないですね

979 ：デフォルトの名無しさん：2021/12/30(木) 19:59:03.54 ID:zuTar3e4.net

>>976
バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない

どこで型が嘘をついているか確実に判断することはむずかしい
自分達の管理するコードベースの外界とのI/Oは全て疑わしい
先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
疑わしい箇所が多すぎる

型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる
信用できない領域がグッと一気に減る
だから型は嘘をついちゃいけないし
簡単に嘘をつける言語仕様は絶対におかしい

980 ：デフォルトの名無しさん：2021/12/30(木) 20:05:16.00 ID:zuTar3e4.net

>>977
構造的部分型もわかりにくいバグの温床だな
anyよりは全然マシだが
まあ楽なのは楽だよそれはわかる
ただ楽なのと安全でりかいしやすいのとは同じじゃないからね

typeは俺が言ったような真の意味で型安全を担保するための仕様
interfaceは構造的部分型でサボるための仕様
こう使い分ければよかったんだろうな

981 ：デフォルトの名無しさん：2021/12/30(木) 20:09:20.24 ID:zuTar3e4.net

>>977
セールポイントであり最大の弱点でもある
思い切って互換性切った方が絶対上手くいってた

>>978
まあ先発の古い言語だからある程度は仕方ないね
Null安全は対応してきてる
イミュータブルは昔から使えてた(final)

982 ：デフォルトの名無しさん：2021/12/30(木) 20:42:46.31 ID:18t9WvJQ.net

>>979
型さえあってりゃどんなライブラリも安全安心だと思っているのか……

983 ：デフォルトの名無しさん：2021/12/30(木) 20:51:38.40 ID:iK2C+Pgo.net

>>982
ちゃんと読めてます？
「信用できない領域がグッと減る」って書いてあるでしょ？

型安全であれば全てが安全なんてことはない
これは常識
でも型安全ならそうでない場合に比べて大部分が安全になる
これも常識

そしてTSは一見すると型安全であるかのように見えるけれど
型が簡単に嘘をつける言語仕様のせいで実は型安全ではなく安全でない言語である
これが私の主張
よく読んでね

984 ：デフォルトの名無しさん：2021/12/30(木) 21:06:33.94 ID:18t9WvJQ.net

>>983
お、これは失敬

985 ：デフォルトの名無しさん：2021/12/30(木) 21:26:07.36 ID:XEA11GKy.net

>>971
あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。

>先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
>疑わしい箇所が多すぎる

嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。
それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。

986 ：デフォルトの名無しさん：2021/12/30(木) 21:31:50.13 ID:XEA11GKy.net

>>972
ああなるほど。
型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。

987 ：デフォルトの名無しさん：2021/12/30(木) 21:32:15.17 ID:yBt1j67p.net

型が嘘をつくってのは
コンパイル時に指定した型以外の値が入ってることがある
入れることが簡単にできるということ

type X = { foo: string }
function xxx(): X

例えば↑こういう定義があったとする
実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？
それはソースコードを隅々まで読んで間違いないことを確認するまでわからない

コードはXという型はfooという文字列型の属性を持っていると主張しているわけだが実際にはそうでない場合がある
これを俺は型が嘘をついていると表現する

988 ：デフォルトの名無しさん：2021/12/30(木) 21:33:00.94 ID:yBt1j67p.net

>>986
ちげーよ

989 ：デフォルトの名無しさん：2021/12/30(木) 21:36:23.80 ID:yBt1j67p.net

JavaやC#ではこういう事は起こらない
正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度
JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい
JavaやC#は型が嘘をつかないからだ

990 ：デフォルトの名無しさん：2021/12/30(木) 21:37:07.94 ID:XEA11GKy.net

>>987
？
おめーのtscはそれコンパイルエラーにしてくれないの？

991 ：デフォルトの名無しさん：2021/12/30(木) 21:39:39.80 ID:rc2c+xCv.net

>>990
本当に恥ずかしいからお前はもう黙ってろ

992 ：デフォルトの名無しさん：2021/12/30(木) 21:39:49.15 ID:yBt1j67p.net

>>990
しない

993 ：デフォルトの名無しさん：2021/12/30(木) 21:42:03.35 ID:18t9WvJQ.net

そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん

994 ：デフォルトの名無しさん：2021/12/30(木) 21:45:32.05 ID:XEA11GKy.net

>>992
コンパイルエラーにならない function xxx() の例よろ。

995 ：デフォルトの名無しさん：2021/12/30(木) 21:57:10.00 ID:hxNkeOah.net

>>993
そだね
選択権があるプロジェクトなら必ずそうしてるよ

996 ：デフォルトの名無しさん：2021/12/30(木) 21:59:52.63 ID:hxNkeOah.net

>>994
function xxx(): X {
return {
foo: bugLib.getStringValueEvil();
}
}

997 ：デフォルトの名無しさん：2021/12/30(木) 22:09:49.35 ID:XEA11GKy.net

>>996
？
bugLib.getStringValueEvil() がstringと宣言されていればコンパイルが通るけどそっちが嘘だったって話？

998 ：デフォルトの名無しさん：2021/12/30(木) 22:21:35.89 ID:hxNkeOah.net

>>997
そう

999 ：デフォルトの名無しさん：2021/12/30(木) 22:24:35.31 ID:XEA11GKy.net

じゃあ bugLib.getStringValueEvil() はどうやって嘘をついたわけ？堂々巡りだが。

1000 ：デフォルトの名無しさん：2021/12/30(木) 22:28:29.05 ID:hxNkeOah.net

>>999
さあどうだろうな？
だから>>987でソースコード隅々まで見たら…って書いたんだけどね

JavaやC#だったら型だけ見ればああこの戻り値のfoo属性は文字列なんだなと信頼できる
ソースコードを隅々まで見る必要はない
なぜなら型が嘘をつかないからね

1001 ：デフォルトの名無しさん：2021/12/30(木) 22:34:32.46 ID:rc2c+xCv.net

anyなんかから型変換する際にランタイムチェックを追加するオプションはあっていいとは思うがTypeScriptにとってのno goalだから無いのも仕方ない
型安全性だけに拘るならTypeScriptは適当じゃないのはそれはそう(そもそもがoptional typeでしかない)

他の要素も考慮すれば個人的には悪い選択肢じゃないのでJavaScriptよりはTypeScriptを選ぶけども(C#やJavaと比較するかは目的による)

1002 ：デフォルトの名無しさん：2021/12/30(木) 22:38:38.66 ID:XEA11GKy.net

ようはTypeScriptに限らず強い型付け以外全否定ってことかね

1003 ：デフォルトの名無しさん：2021/12/30(木) 22:56:16.20 ID:XEA11GKy.net

次スレ立てるよ
http://www.typescriptlang.org/

JavaScript that scales.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

part1
https://peace.5ch.net/test/read.cgi/tech/1349187527/
part2
https://mevius.5ch.net/test/read.cgi/tech/1430386649/
part3
https://mevius.5ch.net/test/read.cgi/tech/1524746903/

1004 ：デフォルトの名無しさん：2021/12/30(木) 22:57:42.38 ID:XEA11GKy.net

TypeScript part4
https://mevius.5ch.net/test/read.cgi/tech/1640872622/

1005 ：デフォルトの名無しさん：2021/12/30(木) 23:01:37.83 ID:chdQ4etC.net

>>1000
それって型指定のバグなわけで、バグを回避する為に他の言語でもソースコード全部読む必要あるのは変わらないのでは……

1006 ：2ch.net投稿限界：Over 1000 Thread

2ch.netからのレス数が1000に到達しました。