TypeScript part3

1 名前：デフォルトの名無しさん [2018/04/26(木) 21:48:23.07 ID:mMDBzDaB.net] 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/ 948 名前：デフォルトの名無しさん mailto:sage [2021/12/07(火) 10:10:01.42 ID:rXzUIf2/.net] 非同期がよーわからん ワーカーを考えない場合 ブラウザでもモバイルでもバックエンドでも基本的に一本のキューにジョブを入れてって順次処理するモデル promiseや 949 名前：awaitを使うと処理の前後関係は保障されるけど間に他のジョブが割り込む可能性がある 処理そのものはシングルスレッドで行われるのでpromiseやawaitを挟まない限り全てのJSコードがアトミックに実行される fetchなどJS外の処理についてはアトミックは保障されない こんな感じであっとる？？？ [] [ここ壊れてます] 950 名前：デフォルトの名無しさん mailto:sage [2021/12/07(火) 22:24:43.13 ID:aDEs4G8x.net] JavaScript Visualized: Event Loop https://dev.to/lydiahallie/javascript-visualized-event-loop-3dif 951 名前：デフォルトの名無しさん mailto:sage [2021/12/08(水) 07:25:06.20 ID:ff6DaDGr.net] >>912 だいたい合ってる。基本的には処理の予約と考えるだけで済む。 JS外の処理はWebWorker含めてJS環境に干渉してこないんだから（戻り値以外）ほぼイベントとか割込と同質で特殊なものだと考える必要もなくないかな？ 952 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 14:21:48.83 ID:h+aQCsXU.net] なんかプロジェクトでtypescript使う流れになって今から勉強してるんだが、これ何に優れてるの？ javascriptの拡張言語で型の宣言できるぐらいがメリット？ 実行するためにいちいちコンパイルもどきなことをしないといけないしデバッグ面倒で正直やりづらいとしか思えないんだが 953 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 14:29:35.72 ID:lTugl+ha.net] 「正直、特別優れた言語設計でもないし、基本的なライブラリ貧弱だし、なんか色々と不安定なので、他の言語を使えるならそっちのがいい。 でもJavaScriptよりかは遥かにマシだからターゲットプラットフォームがブラウザ、ReactNativeなら積極的に使っていこうぜ」ぐらいの認識ですかね 型パズルとかゆるゆるなインターフェースとか最初はこりゃ楽チン、便利だなと思うけどメンテナンス性は疑問 あとTypeScriptは生のJavaScriptよりanyの凶悪さが増してると思う 所詮はALT JSですね 954 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 16:46:11.49 ID:V/6JaBTF.net] >>915 watch使うとわざわざコンパイルする手間が省けるので楽だよ。あとmapファイルも出力するようにすればデバック時も面倒じゃなくなるよ。 型だけじゃなくて、同じコードで古い環境でも動くソースを吐くこともできるよ。 でも、型にメリットを見いださない人向けの言語で無いね。 955 名前：デフォルトの名無しさん mailto:sage [2021/12/09(木) 20:23:42.31 ID:/vSkUWU0.net] 動的型付け言語しか使ったことがない人ならそんなものだよね 956 名前：デフォルトの名無しさん mailto:sage [2021/12/10(金) 13:52:02.48 ID:+cpc+hgB.net] 個人開発だとTypeScriptガンガン使ってる 型パズルたのちい 957 名前：デフォルトの名無しさん mailto:sage [2021/12/10(金) 16:44:26.21 ID:IDIER0Zn.net] 型パズルはアンチパターンだ ほどほどにしとけ 人類はC++を教訓にしなければならない 958 名前：デフォルトの名無しさん mailto:sage [2021/12/10(金) 17:18:46.95 ID:AY2SRHbF.net] TypeScriptにはSFINAEみたいな凶悪な仕様はないだろう。 conditional typeは少し難解かもしれないが自分で使わなければいいだけのことだし。 959 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 11:07:25.83 ID:vugugi2u.net] any型のデータをそれ以外の型に変換可能かどうか判定する、または変換するライブラリってあります？ ↓こんな感じの type T = { id: number; name?: string; timestamp: Date; } const data1: any = { id: 1, name: “bob”, timestamp: new Date() } const t1: = convert<T>(data1); // OK const data2: any = { id: “2”, // number format string timestamp: “2021-12-21T11:00:00Z”, // ISO Date string } const t2 = convert<T>(data2); // OK const data3: any = { // without required field timestamp: new Date() } const t3 = convert<T>(data3); // throw Error const data4: any = { id: 4, timestamp: “hello” // invalid format 960 名前： } const t4 = convert<T>(data4) // throw Error [] [ここ壊れてます] 961 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 11:18:51.59 ID:vugugi2u.net] TypeScriptって型が嘘をつくことが結構あって Date型なのに実行時には文字列が入ってるとか 型定義では省略不可なのに実行時には省略されてるとか そういう実行時の型エラーをなんとかして削減したい、というのが根本的な課題です 上でレスしたようなライブラリがもし有れば多少はマシになるかな、と ランタイムがキャスト例外を投げてくれればそれがベストなんですが、JSに実行時型情報はないのでそれは難しい 962 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 18:51:42.35 ID:X++9NQ8p.net] > JSに実行時型情報はないので つ typeof, instanceof 963 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 19:01:16.33 ID:S4hmWBPH.net] すげー斜め読みしてタイプガードではいかんのかと思った 964 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 19:16:55.14 ID:ESVu6HO8.net] タイプガードでもいいんですけど数が多いので一発で全部よしなにやってくれるものがほしいって感じですかね C#のdynamicのように非互換の代入をその場で例外にしてくれれば楽なんですが なんでかanyは非互換でもエラー無しでスルッと進んでしまうので苦労してます 965 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 19:39:34.82 ID:S6JYHyb7.net] https://github.com/colinhacks/zod 966 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:01:09.90 ID:ESVu6HO8.net] >>927 どうも なかなか良さそうだけどちょっと大変そう 普通の型を先に定義してパーサーを生成するのは難しいんですかね? 967 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:08:19.40 ID:fpjBPgEH.net] TypeScriptのtypeやinterfaceからjsonschemaを生成するライブラリがあるから それを使ってタイプガード書けば楽よ。 968 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:09:36.77 ID:S6JYHyb7.net] https://github.com/azu/create-validator-ts 969 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:12:46.39 ID:S4hmWBPH.net] そういえばAJVがタイプガードに対応してたな 970 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:17:02.00 ID:ESVu6HO8.net] >>930 いいかも あとはanyの代入を自動的に置き換えることができれば完璧 971 名前：デフォルトの名無しさん mailto:sage [2021/12/21(火) 20:28:04.08 ID:S6JYHyb7.net] string -> Date のような transform をしたいなら、型から自動生成を期待するよりもスキーマで変換ロジックを書いて型を導出するアプローチの方が扱いやすい 972 名前：デフォルトの名無しさん mailto:sage [2021/12/23(木) 16:09:01.04 ID:qSHzxodN.net] axiosでの（非同期）通信結果から 最終的にpromiseを外した形でresponse扱いたいんだけど どうやるとできるのでしょうか？ function的な奴で非同期通信して そのfunction自体はpromiseでない値を返したいんだけど。。。 awaitやろうと思うと そのfunctionはasyncになって 結局promiseになってしまう イメージ conct func = (): string => { // axiosの戻りがstringだとして、このvalを同期的に返したい axios.get("hogehoge").then(val=>{return val}) } 973 名前：デフォルトの名無しさん mailto:sage [2021/12/23(木) 20:50:37.85 ID:aMbIyyBR.net] 不可能です 直接 XMLHttpRequest を同期モードで使用してください 974 名前：デフォルトの名無しさん mailto:sage [2021/12/23(木) 22:47:01.90 ID:j1Nwu6l7.net] 非同期を同期にはできない。 これ、初心者の頃は辛かったけど、気がついたら慣れてたし不便さより便利さを感じるようになったから人間の適応能力ってすごい。 975 名前：デフォルトの名無しさん mailto:sage [2021/12/24(金) 11:16:13.19 ID:8YLKxFwi.net] うーんわからん type X = A & { foo: string} ってやるとXがanyと判定される現象が起きてて原因が全くわからない Aはちゃんと型が認識されてる const a: A = { 略 } a. ここまで打てばインテリセンスが出てくる でも&を挟むとなぜかanyになる コンパイラのバグかな？ 976 名前：デフォルトの名無しさん mailto:sage [2021/12/24(金) 12:01:47.45 ID:vCO0x3fk.net] export type X = A & { foo: string } const x: X これは型が生きてるしインテリセンスも出る import { X } from ‘…’ const x: X これはanyになってしまう ファイルを 977 名前：跨がなければおkみたい エクスポート/インポートのプロセスでバグるのかな？ 他の型は問題出てないからAだけが特殊なんだろうけど文字列型のフィールド幾つか持ってるだけのなんの変哲もない型なんだよな… [] [ここ壊れてます] 978 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 12:39:31.39 ID:mJNzEC98.net] 色々調べて行き詰まったんだけどこれで合ってる？ babelのpreset-typescriptはTSから形情報を落としてるだけ なのでtsconfigを無視する なのでproject referencesも無視される プロジェクト分割したい場合のオフィシャルな手段がない なのでプロジェクト分割したければ各自好きな方法でハックするしかない 暫定対応として被参照側のプロジェクトでwatch & buildを仕掛けて babel側のプロジェクトから被参照側の出力フォルダをimportしてるんだけど正直辛いものがある 979 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 13:16:26.59 ID:YYlOH5kW.net] babel がどう動くかなんて tsc には関係ないだろ それともあなたのエディタは babel で型情報を解析しているのか？ 980 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 13:22:25.16 ID:YYlOH5kW.net] コンパイル済みのファイルに型情報がないという話なら、型定義ファイル(.d.ts)も出力しないとそりゃそうだろと 981 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 13:40:07.40 ID:mJNzEC98.net] プロジェクト分割についてはどう考えますか？ 982 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 13:54:01.89 ID:YYlOH5kW.net] 情報を小出しにせず、問題が再現するリポジトリ丸ごと上げるかせめてファイル構造や各種設定ファイルの内容など全部書き出して & がダメなのかファイルを跨ぐのがダメなのかプロジェクト分割がダメなのか話がどんどん移っててわからんぞ 983 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 14:17:47.06 ID:YYlOH5kW.net] これ別人の別の話か…そうだったらスマン 984 名前：デフォルトの名無しさん mailto:sage [2021/12/25(土) 14:25:06.24 ID:mJNzEC98.net] 別ですね 単刀直入に言うとbabel & preset -typescript環境で正しいプロジェクト分割のしかたを聞きたかった 985 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 11:58:10.04 ID:yczrikVs.net] 色々と試して結論が出た プロジェクト参照は諦めてシンプルに相対パスでimportすることにした 依存パッケージを全てのプロジェクトに入れなければならないのが面倒だけど妥協 ようするに昔VB6やC言語などでよくやってたDLL化せずにコードファイルを共有するスタイル モダンな言語でやることとは思えないけど何日も調べてできないなら仕方ない 986 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 12:26:32.69 ID:6ScHvZpk.net] バベるのが悪い 987 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 16:05:00.89 ID:SvIlyqah.net] でもフレームワークがバベれって言うんです 988 名前：デフォルトの名無しさん mailto:sage [2021/12/26(日) 16:14:53.21 ID:imvxWhRx.net] これを babel_proj webpack_proj tsc_proj 　tsconfig.json tsc_lib_1 　tsconfig.json tsc_lib_2 　tsconfig.json こうする babel_proj 　symlink => ../libs webpack_proj 　symlink => ../libs tsc_proj 　tsconfig.json 　symlink => ../libs libs 　lib_1 　lib_2 989 名前：デフォルトの名無しさん mailto:sage [2021/12/28(火) 17:28:42.45 ID:X7A0KCIT.net] バックエンドはexpress一択？ 990 名前：デフォルトの名無しさん mailto:sage [2021/12/28(火) 20:29:49.68 ID:qjWVy58S.net] そんな🍌 991 名前：デフォルトの名無しさん mailto:sage [2021/12/28(火) 23:38:51.88 ID:QExnrlZb.net] 僕はFastify! 992 名前：デフォルトの名無しさん mailto:sage [2021/12/29(水) 02:36:36.80 ID:tTEsT75E.net] nestjsはレガシーなデコレータ依存がなあ 993 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 13:04:36.50 ID:8IVD/YcY.net] そもそもサーバーサイドにTS選ぶメリットが無い 994 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 13:42:00.99 ID:XEA11GKy.net] JavaScriptがって話ならわからんでもないが 995 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 13:49:04.54 ID:8IVD/YcY.net] TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ フロントエンドでは気楽さと壊れやすさのトレードオフってことで受け入れるけど 996 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 13:53:13.25 ID:XEA11GKy.net] じゃあC/C++なんかもダメだな 997 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 14:00:36.67 ID:qk2rIpzk.net] バリデーションもできない奴がなんか言ってら 998 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 14:01:03.11 ID:8IVD/YcY.net] そうだね バックエンドでは実 999 名前：質Cと大差ない ちょっとだけ楽できるけど [] [ここ壊れてます] 1000 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 14:10:38.20 ID:XEA11GKy.net] じゃあ逆にバックエンドで受け入れられる言語ってなんだろう？JavaとかRustくらい？ 1001 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 14:23:51.58 ID:8IVD/YcY.net] JavaとC#だね 型安全性がしっかりしてて実績も多い言語って言えばそれぐらいじゃないか？ 1002 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 14:42:45.86 ID:XEA11GKy.net] んー、つまり >TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ JavaとC#以外の言語を触るたびに同じように思ったってことでいいのかな？ 1003 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 15:01:47.81 ID:Q5xANRZc.net] まあ、そうだね 1004 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 16:23:51.89 ID:se0ux0qB.net] C♯やJavaよりはTypeScriptやRust選びますわ 1005 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 16:31:34.51 ID:tab5g/QS.net] そしてバグが出ると 1006 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 16:52:28.72 ID:XEA11GKy.net] まるでTypeScriptやRustを選ぶとバグが出るかのような物言いだが C#やJavaを選べばバグが出ないというわけでもあるない 1007 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 17:38:29.90 ID:tab5g/QS.net] TypeScriptは型が簡単に嘘をつけるのでバグが出やすい 型安全性がバグ削減に貢献しているのはプログラマの常識 1008 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 17:46:55.74 ID:18t9WvJQ.net] それはあなたがバリデーション書けないからでしょ？ 1009 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 17:56:31.58 ID:XEA11GKy.net] >>967 具体的にどういうのを言っている？まさか故意にasでキャストした場合の話じゃないだろうが 1010 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 18:04:13.25 ID:cY7zFSmj.net] その返答で書けないということが露呈したゾ 1011 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:17:21.94 ID:zuTar3e4.net] >>968 型が嘘をつけることとバリデーションは別次元の話 >>969 明示的キャストなんかしなくてもTSにはいくらでも型が嘘をつく罠がある 代表的なところだとjsonのパース、DBのI/O、api I/O、野良ライブラリのI/O、、、 1012 名前：デフォルトの名無しさん mailto:sage [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は消えるべき 1013 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:33:44.30 ID:18t9WvJQ.net] >>972 いやそれはそのコードがバカじゃん…… 1014 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:34:37.32 ID:zuTar3e4.net] Javaは最も優れた設計でそもそもanyみたいな言語仕様がない Objectは定義できるが暗黙のキャストでスルッと行くなんてことはあり得ないし無理やりキャストしたって実行時に必ず例外が飛ぶ C#はanyに近いものでdynamicというのがあるがこれも誤ったキャストには実行時に例外が飛ぶ どちらも型が嘘をつかないように言語基盤がしっかり担保してくれるから型を信用していい 当たり前のことを当たり前にやってくれる堅実な言語だ 1015 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:36:08.35 ID:zuTar3e4.net] >>973 このコードは説明のためのスニペットだ 現実的にこんなコード書くわけないだろ 現実的には先に挙げたような状況でanyと戦わなければならない 1016 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:44:03.93 ID:18t9WvJQ.net] >>971 >>975 なんの為のバリデーションとタイプガードだよ。 どこで間違った型が入りうるかなんか普通把握できるでしょうに 1017 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:48:28.03 ID:pcTvcAXH.net] Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ 構造的部分型も便利だしany型なんて使うときには型ガードするよね 型に関してはJavaより好きだわ 1018 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:51:25.70 ID:HvA/IBjD.net] Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと 1019 名前：信用できないですね [] [ここ壊れてます] 1020 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 19:59:03.54 ID:zuTar3e4.net] >>976 バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない どこで型が嘘をついているか確実に判断することはむずかしい 自分達の管理するコードベースの外界とのI/Oは全て疑わしい 先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO 疑わしい箇所が多すぎる 型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる 信用できない領域がグッと一気に減る だから型は嘘をついちゃいけないし 簡単に嘘をつける言語仕様は絶対におかしい 1021 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 20:05:16.00 ID:zuTar3e4.net] >>977 構造的部分型もわかりにくいバグの温床だな anyよりは全然マシだが まあ楽なのは楽だよそれはわかる ただ楽なのと安全でりかいしやすいのとは同じじゃないからね typeは俺が言ったような真の意味で型安全を担保するための仕様 interfaceは構造的部分型でサボるための仕様 こう使い分ければよかったんだろうな 1022 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 20:09:20.24 ID:zuTar3e4.net] >>977 セールポイントであり最大の弱点でもある 思い切って互換性切った方が絶対上手くいってた >>978 まあ先発の古い言語だからある程度は仕方ないね Null安全は対応してきてる イミュータブルは昔から使えてた(final) 1023 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 20:42:46.31 ID:18t9WvJQ.net] >>979 型さえあってりゃどんなライブラリも安全安心だと思っているのか…… 1024 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 20:51:38.40 ID:iK2C+Pgo.net] >>982 ちゃんと読めてます？ 「信用できない領域がグッと減る」って書いてあるでしょ？ 型安全であれば全てが安全なんてことはない これは常識 でも型安全ならそうでない場合に比べて大部分が安全になる これも常識 そしてTSは一見すると型安全であるかのように見えるけれど 型が簡単に嘘をつける言語仕様のせいで実は型安全ではなく安全でない言語である これが私の主張 よく読んでね 1025 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:06:33.94 ID:18t9WvJQ.net] >>983 お、これは失敬 1026 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:26:07.36 ID:XEA11GKy.net] >>971 あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。 >先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO >疑わしい箇所が多すぎる 嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。 それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。 1027 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:31:50.13 ID:XEA11GKy.net] >>972 ああなるほど。 型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。 1028 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:32:15.17 ID:yBt1j67p.net] 型が嘘をつくってのは コンパイル時に指定した型以外の値が入ってることがある 入れることが簡単にできるということ type X = { foo: string } function xxx(): X 例えば↑こういう定義があったとする 実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？ それはソースコードを隅々まで読んで間違いないことを確認するまでわからない コードはXという型はfooという文字列型の属性を持っていると主張しているわけだが実際にはそうでない場合がある これを俺は型が嘘をついていると表現する 1029 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:33:00.94 ID:yBt1j67p.net] >>986 ちげーよ 1030 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:36:23.80 ID:yBt1j67p.net] JavaやC#ではこういう事は起こらない 正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度 JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい JavaやC#は型が嘘をつかないからだ 1031 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:37:07.94 ID:XEA11GKy.net] >>987 ？ おめーのtscはそれコンパイルエラーにしてくれないの？ 1032 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:39:39.80 ID:rc2c+xCv.net] >>99 1033 名前：0 本当に恥ずかしいからお前はもう黙ってろ [] [ここ壊れてます] 1034 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:39:49.15 ID:yBt1j67p.net] >>990 しない 1035 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:42:03.35 ID:18t9WvJQ.net] そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん 1036 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:45:32.05 ID:XEA11GKy.net] >>992 コンパイルエラーにならない function xxx() の例よろ。 1037 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:57:10.00 ID:hxNkeOah.net] >>993 そだね 選択権があるプロジェクトなら必ずそうしてるよ 1038 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 21:59:52.63 ID:hxNkeOah.net] >>994 function xxx(): X { return { foo: bugLib.getStringValueEvil(); } } 1039 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:09:49.35 ID:XEA11GKy.net] >>996 ？ bugLib.getStringValueEvil() がstringと宣言されていればコンパイルが通るけどそっちが嘘だったって話？ 1040 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:21:35.89 ID:hxNkeOah.net] >>997 そう 1041 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:24:35.31 ID:XEA11GKy.net] じゃあ bugLib.getStringValueEvil() はどうやって嘘をついたわけ？堂々巡りだが。 1042 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:28:29.05 ID:hxNkeOah.net] >>999 さあどうだろうな？ だから>>987でソースコード隅々まで見たら…って書いたんだけどね JavaやC#だったら型だけ見ればああこの戻り値のfoo属性は文字列なんだなと信頼できる ソースコードを隅々まで見る必要はない なぜなら型が嘘をつかないからね 1043 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:34:32.46 ID:rc2c+xCv.net] anyなんかから型変換する際にランタイムチェックを追加するオプションはあっていいとは思うがTypeScriptにとってのno goalだから無いのも仕方ない 型安全性だけに拘るならTypeScriptは適当じゃないのはそれはそう(そもそもがoptional typeでしかない) 他の要素も考慮すれば個人的には悪い選択肢じゃないのでJavaScriptよりはTypeScriptを選ぶけども(C#やJavaと比較するかは目的による) 1044 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:38:38.66 ID:XEA11GKy.net] ようはTypeScriptに限らず強い型付け以外全否定ってことかね 1045 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:56:16.20 ID:XEA11GKy.net] 次スレ立てるよ 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/ 1046 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 22:57:42.38 ID:XEA11GKy.net] TypeScript part4 https://mevius.5ch.net/test/read.cgi/tech/1640872622/ 1047 名前：デフォルトの名無しさん mailto:sage [2021/12/30(木) 23:01:37.83 ID:chdQ4etC.net] >>1000 それって型指定のバグなわけで、バグを回避する為に他の言語でもソースコード全部読む必要あるのは変わらないのでは…… 1048 名前：1001 [Over 1000 Thread.net] このスレッドは１０００を超えました。 新しいスレッドを立ててください。 life time: 1344日 1時間 13分 15秒

---

---

[ 続きを読む ] / [ 携帯版 ]

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef