TypeScript part3 - 暇つぶし2ch

TypeScript part3 at TECH

[前50を表示]
900:デフォルトの名無しさん
21/10/19 21:14:06.31 QUfGkxyV.net
>>863
何がやりたいかわかんね～
myFuncさえ登録できりゃ発展形でやり様子はあると思うけど

901:デフォルトの名無しさん
21/10/28 09:19:43.09 Qx9i2vDk.net
変数の先頭に$を付けるのは何の意味があるのでしょう？

902:デフォルトの名無しさん
21/10/28 09:36:01.90 3VMLYSLP.net
そんな事しません

903:デフォルトの名無しさん
21/10/28 23:51:25.40 vOpe/LV1.net
DOM のエレメントだよって示す

904:デフォルトの名無しさん
21/10/29 00:01:40.58 e9XHTkBz.net
PHPerでも出来た！と主張する

905:デフォルトの名無しさん
21/10/31 10:32:24.95 gOKmIPxI.net
Cの __FILE__ や __LINE__ みたいにトランスパイル前のファイル名や行番号を埋め込む方法って無いのかな？
一応source-map-supportでスタックトレースは読めるようになったけど、もっと手軽に埋め込むログで
場所を示せたらいいんだが。

906:デフォルトの名無しさん
21/10/31 12:11:14.90 Xdv2iZD2.net
TypeScript の仕事じゃない

907:デフォルトの名無しさん
21/10/31 12:31:29.22 gOKmIPxI.net
tscの前にプリプロセッサとかかまして実現できるならそれでもいいんだけど。

908:デフォルトの名無しさん
21/10/31 12:33:38.24 OQlLkoA+.net
しょせんはトランスパイラ
多くを求めたらダメだ

909:デフォルトの名無しさん
21/10/31 21:52:21.68 plSPEajD.net
>>871
英語で議論できれば提案すればいいと思うけどね

910:デフォルトの名無しさん
21/10/31 22:25:46.49 +4LFgdgS.net
>>873
手動でやるのは簡単だよね？
TS使ってないからビルドシステム知らんけど、Pythonか何かを挟み込める余地があったらそこでやってしまえば？
或いはいっそのことmakefileでラップしてしまうとか。(makefile内でビルドコマンドを起動）

911:デフォルトの名無しさん
21/10/31 23:58:24.90 gOKmIPxI.net
ありがとう。無いってことね。

912:871
21/11/01 00:27:26.36 M14pmKjL.net
>>877
多分ね。（俺は871、TS使ってない）
他言語（何だったかは忘れた）でも同様に「ないのか？」って聞かれてて、
仕様に入れない理由が「ちゃんと関数名書け」だったと思ったよ。
実際あれって、実装するのは簡単だけど、Cにしかないでしょ。
個人開発ならともかく、Gitな今だと複数バージョンが同時に使われてたりするから、収拾付かなくなるのではないかな。
その辺のCの便利機能って、今の大規模開発にはフィットしないから、基本的には嫌われてる。
多分、提案したところで入らない。

913:デフォルトの名無しさん
21/11/01 00:59:41.61 KlMso67D.net
TypeScriptのポリシー的に絶対入らない

914:デフォルトの名無しさん
21/11/01 08:42:35.30 43zjctJQ.net
技術的にそう難しくもなさそうなのに今無いってことはもう入れられる見込みは無いんだろうけど
これが絶対に相容れられないようなポリシーってなんかあったかな？

915:デフォルトの名無しさん
21/11/01 18:25:45.93 ZjFzlu/6.net
TSって滅多にクラス使わないけどDIってどうやってんの？

916:デフォルトの名無しさん
21/11/01 20:45:04.19 bXtGRcPZ.net
クラス全く使わないわけじゃないよ。まぁ明示的に副作用使いたい時ぐらいしか使わないけど

917:デフォルトの名無しさん
21/11/11 15:10:53.10 CHcG8Nbi.net
DIの件はこれで解決した
function F(deps: { … }, p1: T1, p2: T2)
よくよく考えると
たったこれだけのことだったんだ
フレームワークとかややこしいことを考えたのが間違いだった

918:デフォルトの名無しさん
21/11/11 19:34:48.71 CHcG8Nbi.net
type X = {
foo: string;
bar: string;
baz: string;
}
この型から
type Y = {
foo: string;
bar: string;
}
この型をMappedTypesで定義したい
つまり特定の属性を除去した型を作りたいのだけど出来る？

919:デフォルトの名無しさん
21/11/11 21:14:57.72 P2a3zHOn.net
Utility Types の Omit とか。

920:デフォルトの名無しさん
21/11/16 12:37:58.33 Gu6EBfCm.net
.NETでいうところの.NET StandardのようなものってTSには無いの？
フルスタックでTS使う案件に間違って入っちゃったんだけど環境ごとに何が出来るのか把�

921:ｬしきれなくてツラミを感じるストリームと文字列の処理みたいな「こんなもんどの環境でも動くだろ」ってコードすら移植すると動かない時があって泣きそうスタンダードなライブラリが無いならビルダーの設定でもいい tsconfigでターゲットプラットフォームとランタイムバージョンを指定すると「このパッケージはこのターゲットプラットフォームでは使えないよ」って教えてくれるだけでもだいぶ楽になると思うんだけど… こういう機能ってどっかに絶対あると思うんだけどググっても古い断片的な情報ばっかり出てきてその設定を探すのも難しい

922:デフォルトの名無しさん
21/11/17 21:29:35.22 h3+MjybB.net
主な実行環境として node.js とブラウザがあるってことはわかってる？

923:デフォルトの名無しさん
21/11/18 00:15:24.62 3dlOBCKi.net
あとは泥とりんごでしょ？
せめてその4つのメジャーな環境でほぼほぼ同じように動く基本ライブラリ、基本ライブラリだけに依存して、つまりほぼほぼどこでも動くサードパーティライブラリ
それらが日常的な作業に不自由しないレベルで揃ってて然るべきだろう、と俺は思うんだけど無いのかな？

924:デフォルトの名無しさん
21/11/18 00:23:00.28 cf0G7PVa.net
基本ライブラリというならJavaScript API群があるが。
「日常的な作業に不自由しないレベル」って具体的にはどんなものを期待している？

925:デフォルトの名無しさん
21/11/18 00:34:29.18 3dlOBCKi.net
.NET Standardぐらいの想定かな

926:デフォルトの名無しさん
21/11/18 06:41:05.66 In+gpp4R.net
まず.NETが世界の中心。みんな知ってるだろ全部揃ってて当然だろみたいな考え方をやめろ。
フロント側についてはサイの絵が書いてある本買ってくるか、MDNを熟読すれば良い。Node側はNodeの公式を読め。話はそれから。
あとはtsconfigのcompilerOptions以下のtargetとlibを指定しろ。この辺はNodeのバージョンや、対象ブラウザで変わるからググれ。すぐ出てくる。

927:デフォルトの名無しさん
21/11/18 07:16:30.61 te8WLqUU.net
> 主な実行環境として node.js とブラウザがあるってことはわかってる？
> あとは泥とりんごでしょ？
これわかってないだろ

928:デフォルトの名無しさん
21/11/18 08:57:28.17 Ip1KYC/r.net
Announcing TypeScript 4.5
URLﾘﾝｸ(devblogs.microsoft.com)

929:デフォルトの名無しさん
21/11/18 12:49:52.50 xCTrnppv.net
自分は知っているみたいな錯覚してるせいで根本的に間違ってることに気づいてない

930:デフォルトの名無しさん
21/11/18 12:57:37.30 3dlOBCKi.net
URLﾘﾝｸ(stackoverflow.com)
適当にググったらこんなんあったけど、
要するに、こういうことだよな
これはただの一例だけど、ストリームと文字列の変換なんてなんかはさ、いいかい？
全ての開発者が、ドキュメントを熟読せず、何の迷いもなく、インテリセンスに導かれて、スラスラと書けてだよ
そして、それが驚き最小で、思った通りに動作する
それがモダンな高級言語として、当たり前の姿なんじゃないのかい？
TSのメンテナは真新しさばかり追い求めて、足場を固めるという、地味だが大切な仕事を忘れてやしないか？

931:デフォルトの名無しさん
21/11/18 13:22:17.68 In+gpp4R.net
根本的な勘違いとして、それはTypeScriptの責務では無い。TypeScriptはJavaScriptにモダンな型を付与するもの（一部例外はある）で、APIの提供はしない。
例に出てきたFileReaderの様なAPIはブラウザとNode側で求められる機能もセキュリティレベルも異なり、それぞれが提供するものだ。それを統一はできない。ましてnpmのバッケージで提供されているものはパッケージ作者が責務を負うものだ。
自分の勉強不足を棚に上げて言語に文句を言うのは筋違いも

932:良いとこ。

933:デフォルトの名無しさん
21/11/18 14:09:39.19 3dlOBCKi.net
そこがTSの限界であり、使いにくい原因なんだろなぁ
FileReaderなんてのはたまたま出てきた一例でしかないが
リンク先のポストを読めば、トピ主のやりたいことはストリームから文字列への変換とわかるだろう
その程度はどのプラットフォームでもサポートできる
使用頻度もそこそこだから、標準ライブラリとして用意されていて当たり前
encode(s: string, format: string): Blob
decode(b: Blob, format: string): string
これでいいだろ？
セキュリティやハードウェアに依存するものが標準化されないのは許されるだろう
しかしなぜ簡単にできるものすら標準化しない？

934:デフォルトの名無しさん
21/11/18 16:35:20.00 In+gpp4R.net
そのストリームってのは何のストリーム？
ひょっとして用語を間違えてるから調べても出てこないのでは？

935:デフォルトの名無しさん
21/11/19 07:13:45.00 UKAZMSSR.net
>>893
型演算に末尾再帰最適化（みたいなの）追加されるやん！

936:デフォルトの名無しさん
21/11/21 12:03:30.92 lhVIl0/s.net
型の@types だけインポートするにはどうしたらよいでしょうか。
leafletという地図のjsライブラリがあって、グローバルでL という変数をnamespaceとして使っています。
npmの層を薄くしたくて、地図ライブラリはnpm を使わずにhtmlにscriptタグを直接書いて読み込んでいます。
でも型補完は欲しいので、"@types/leaflet"はnpmでインストールしています。
この状態で変数L に型補完を動作させるにはどうすればよいでしょうか。
何もしないと、変数Lは未定義だよというエラーが出ます。
(エラーを消すだけなら適当なd.tsを作って declare const L: any; とでも書けばいいんだろうけど)

937:デフォルトの名無しさん
21/11/21 12:42:32.36 9+9LY8kt.net
import type * as Leaflet from 'leaflet'
declare const L: typeof Leaflet

938:デフォルトの名無しさん
21/11/21 12:53:04.47 lhVIl0/s.net
ありがとうございます

939:デフォルトの名無しさん
21/11/23 00:51:46.26 6fLWx+hU.net
空配列ってどうやって定義すればいいんでしょうか？

940:デフォルトの名無しさん
21/11/24 20:42:59.28 KtJ2oMe7.net
Dateが使いにくいのどうにかする最高のライブラリ教えてよ
date-nfs、momentあたりは試したけどしっくりこんかったわ
JSONが非対称ってのもSo Badやでほんま
よくこんな罠だらけの言語でやってられるなー
フロントエンド勢の忍耐力には尊敬の念を禁じえんわい

941:デフォルトの名無しさん
21/11/24 21:53:47.96 mN6taiyI.net
>>904
> JSONが非対称
とは？
JSON.parse, JSON.stringify 知ってるか？

942:デフォルトの名無しさん
21/11/24 22:01:40.70 zBacYw4i.net
>>904
date-nfsで駄目ならオススメは無いかなぁ。
ご指摘の通り罠も多いけどC++とかに比べたらずっと楽な言語だと思うな

943:デフォルトの名無しさん
21/11/24 23:40:29.12 FcSkbZGe.net
>>904
> Dateが使いにくいのどうにかする
そんなあなたに Temporal

944:デフォルトの名無しさん
21/11/26 22:12:29.88 +KFAtmTP.net
Effective TypeScript
ちと古いが読んだ方がいい？

945:デフォルトの名無しさん
21/12/02 17:06:08.00 kge1UpiO.net
あーくそ
なんでstrictをOFFにできるんだよ
VB.NETか！

946:デフォルトの名無しさん
21/12/02 18:20:28.57 Kt63btcl.net
いやなんでfalseにするんだよ

947:デフォルトの名無しさん
21/12/02 22:30:30.27 Ki4y/ScD.net
既存の JavaScript を段階的に移行したい時かな

948:デフォルトの名無しさん
21/12/07 10:10:01.42 rXzUIf2/.net
非同期がよーわからん
ワーカーを考えない場合
ブラウザでもモバイルでもバックエンドでも基本的に一本のキューにジョブを入れてって順次処理するモデル
promiseや

949:awaitを使うと処理の前後関係は保障されるけど間に他のジョブが割り込む可能性がある処理そのものはシングルスレッドで行われるのでpromiseやawaitを挟まない限り全てのJSコードがアトミックに実行される fetchなどJS外の処理についてはアトミックは保障されないこんな感じであっとる？？？

950:デフォルトの名無しさん
21/12/07 22:24:43.13 aDEs4G8x.net
JavaScript Visualized: Event Loop
URLﾘﾝｸ(dev.to)

951:デフォルトの名無しさん
21/12/08 07:25:06.20 ff6DaDGr.net
>>912
だいたい合ってる。基本的には処理の予約と考えるだけで済む。
JS外の処理はWebWorker含めてJS環境に干渉してこないんだから（戻り値以外）ほぼイベントとか割込と同質で特殊なものだと考える必要もなくないかな？

952:デフォルトの名無しさん
21/12/09 14:21:48.83 h+aQCsXU.net
なんかプロジェクトでtypescript使う流れになって今から勉強してるんだが、これ何に優れてるの？
javascriptの拡張言語で型の宣言できるぐらいがメリット？
実行するためにいちいちコンパイルもどきなことをしないといけないしデバッグ面倒で正直やりづらいとしか思えないんだが

953:デフォルトの名無しさん
21/12/09 14:29:35.72 lTugl+ha.net
「正直、特別優れた言語設計でもないし、基本的なライブラリ貧弱だし、なんか色々と不安定なので、他の言語を使えるならそっちのがいい。
でもJavaScriptよりかは遥かにマシだからターゲットプラットフォームがブラウザ、ReactNativeなら積極的に使っていこうぜ」ぐらいの認識ですかね
型パズルとかゆるゆるなインターフェースとか最初はこりゃ楽チン、便利だなと思うけどメンテナンス性は疑問
あとTypeScriptは生のJavaScriptよりanyの凶悪さが増してると思う
所詮はALT JSですね

954:デフォルトの名無しさん
21/12/09 16:46:11.49 V/6JaBTF.net
>>915
watch使うとわざわざコンパイルする手間が省けるので楽だよ。あとmapファイルも出力するようにすればデバック時も面倒じゃなくなるよ。
型だけじゃなくて、同じコードで古い環境でも動くソースを吐くこともできるよ。
でも、型にメリットを見いださない人向けの言語で無いね。

955:デフォルトの名無しさん
21/12/09 20:23:42.31 /vSkUWU0.net
動的型付け言語しか使ったことがない人ならそんなものだよね

956:デフォルトの名無しさん
21/12/10 13:52:02.48 +cpc+hgB.net
個人開発だとTypeScriptガンガン使ってる
型パズルたのちい

957:デフォルトの名無しさん
21/12/10 16:44:26.21 IDIER0Zn.net
型パズルはアンチパターンだ
ほどほどにしとけ
人類はC++を教訓にしなければならない

958:デフォルトの名無しさん
21/12/10 17:18:46.95 AY2SRHbF.net
TypeScriptにはSFINAEみたいな凶悪な仕様はないだろう。
conditional typeは少し難解かもしれないが自分で使わなければいいだけのことだし。

959:デフォルトの名無しさん
21/12/21 11:07:25.83 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:デフォルトの名無しさん
21/12/21 11:18:51.59 vugugi2u.net
TypeScriptって型が嘘をつくことが結構あって
Date型なのに実行時には文字列が入ってるとか
型定義では省略不可なのに実行時には省略されてるとか
そういう実行時の型エラーをなんとかして削減したい、というのが根本的な課題です
上でレスしたようなライブラリがもし有れば多少はマシになるかな、と
ランタイムがキャスト例外を投げてくれればそれがベストなんですが、JSに実行時型情報はないのでそれは難しい

962:デフォルトの名無しさん
21/12/21 18:51:42.35 X++9NQ8p.net
> JSに実行時型情報はないので
つ typeof, instanceof

963:デフォルトの名無しさん
21/12/21 19:01:16.33 S4hmWBPH.net
すげー斜め読みしてタイプガードではいかんのかと思った

964:デフォルトの名無しさん
21/12/21 19:16:55.14 ESVu6HO8.net
タイプガードでもいいんですけど数が多いので一発で全部よしなにやってくれるものがほしいって感じですかね
C#のdynamicのように非互換の代入をその場で例外にしてくれれば楽なんですが
なんでかanyは非互換でもエラー無しでスルッと進んでしまうので苦労してます

965:デフォルトの名無しさん
21/12/21 19:39:34.82 S6JYHyb7.net
URLﾘﾝｸ(github.com)

966:デフォルトの名無しさん
21/12/21 20:01:09.90 ESVu6HO8.net
>>927
どうも
なかなか良さそうだけどちょっと大変そう
普通の型を先に定義してパーサーを生成するのは難しいんですかね?

967:デフォルトの名無しさん
21/12/21 20:08:19.40 fpjBPgEH.net
TypeScriptのtypeやinterfaceからjsonschemaを生成するライブラリがあるから
それを使ってタイプガード書けば楽よ。

968:デフォルトの名無しさん
21/12/21 20:09:36.77 S6JYHyb7.net
URLﾘﾝｸ(github.com)

969:デフォルトの名無しさん
21/12/21 20:12:46.39 S4hmWBPH.net
そういえばAJVがタイプガードに対応してたな

970:デフォルトの名無しさん
21/12/21 20:17:02.00 ESVu6HO8.net
>>930
いいかも
あとはanyの代入を自動的に置き換えることができれば完璧

971:デフォルトの名無しさん
21/12/21 20:28:04.08 S6JYHyb7.net
string -> Date のような transform をしたいなら、型から自動生成を期待するよりもスキーマで変換ロジックを書いて型を導出するアプローチの方が扱いやすい

972:デフォルトの名無しさん
21/12/23 16:09:01.04 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:デフォルトの名無しさん
21/12/23 20:50:37.85 aMbIyyBR.net
不可能です
直接 XMLHttpRequest を同期モードで使用してください

974:デフォルトの名無しさん
21/12/23 22:47:01.90 j1Nwu6l7.net
非同期を同期にはできない。
これ、初心者の頃は辛かったけど、気がついたら慣れてたし不便さより便利さを感じるようになったから人間の適応能力ってすごい。

975:デフォルトの名無しさん
21/12/24 11:16:13.19 8YLKxFwi.net
うーんわからん
type X = A & { foo: string}
ってやるとXがanyと判定される現象が起きてて原因が全くわからない
Aはちゃんと型が認識されてる
const a: A = { 略 }
a.
ここまで打てばインテリセンスが出てくる
でも&を挟むとなぜかanyになる
コンパイラのバグかな？

976:デフォルトの名無しさん
21/12/24 12:01:47.45 vCO0x3fk.net
export type X = A & { foo: string }
const x: X
これは型が生きてるしインテリセンスも出る
import { X } from ‘…’
const x: X
これはanyになってしまう
ファイルを

977:跨がなければおkみたいエクスポート/インポートのプロセスでバグるのかな？他の型は問題出てないからAだけが特殊なんだろうけど文字列型のフィールド幾つか持ってるだけのなんの変哲もない型なんだよな…

978:デフォルトの名無しさん
21/12/25 12:39:31.39 mJNzEC98.net
色々調べて行き詰まったんだけどこれで合ってる？
babelのpreset-typescriptはTSから形情報を落としてるだけ
なのでtsconfigを無視する
なのでproject referencesも無視される
プロジェクト分割したい場合のオフィシャルな手段がない
なのでプロジェクト分割したければ各自好きな方法でハックするしかない
暫定対応として被参照側のプロジェクトでwatch & buildを仕掛けて
babel側のプロジェクトから被参照側の出力フォルダをimportしてるんだけど正直辛いものがある

979:デフォルトの名無しさん
21/12/25 13:16:26.59 YYlOH5kW.net
babel がどう動くかなんて tsc には関係ないだろ
それともあなたのエディタは babel で型情報を解析しているのか？

980:デフォルトの名無しさん
21/12/25 13:22:25.16 YYlOH5kW.net
コンパイル済みのファイルに型情報がないという話なら、型定義ファイル(.d.ts)も出力しないとそりゃそうだろと

981:デフォルトの名無しさん
21/12/25 13:40:07.40 mJNzEC98.net
プロジェクト分割についてはどう考えますか？

982:デフォルトの名無しさん
21/12/25 13:54:01.89 YYlOH5kW.net
情報を小出しにせず、問題が再現するリポジトリ丸ごと上げるかせめてファイル構造や各種設定ファイルの内容など全部書き出して
& がダメなのかファイルを跨ぐのがダメなのかプロジェクト分割がダメなのか話がどんどん移っててわからんぞ

983:デフォルトの名無しさん
21/12/25 14:17:47.06 YYlOH5kW.net
これ別人の別の話か…そうだったらスマン

984:デフォルトの名無しさん
21/12/25 14:25:06.24 mJNzEC98.net
別ですね
単刀直入に言うとbabel & preset -typescript環境で正しいプロジェクト分割のしかたを聞きたかった

985:デフォルトの名無しさん
21/12/26 11:58:10.04 yczrikVs.net
色々と試して結論が出た
プロジェクト参照は諦めてシンプルに相対パスでimportすることにした
依存パッケージを全てのプロジェクトに入れなければならないのが面倒だけど妥協
ようするに昔VB6やC言語などでよくやってたDLL化せずにコードファイルを共有するスタイル
モダンな言語でやることとは思えないけど何日も調べてできないなら仕方ない

986:デフォルトの名無しさん
21/12/26 12:26:32.69 6ScHvZpk.net
バベるのが悪い

987:デフォルトの名無しさん
21/12/26 16:05:00.89 SvIlyqah.net
でもフレームワークがバベれって言うんです

988:デフォルトの名無しさん
21/12/26 16:14:53.21 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:デフォルトの名無しさん
21/12/28 17:28:42.45 X7A0KCIT.net
バックエンドはexpress一択？

990:デフォルトの名無しさん
21/12/28 20:29:49.68 qjWVy58S.net
そんな🍌

991:デフォルトの名無しさん
21/12/28 23:38:51.88 QExnrlZb.net
僕はFastify!

992:デフォルトの名無しさん
21/12/29 02:36:36.80 tTEsT75E.net
nestjsはレガシーなデコレータ依存がなあ

993:デフォルトの名無しさん
21/12/30 13:04:36.50 8IVD/YcY.net
そもそもサーバーサイドにTS選ぶメリットが無い

994:デフォルトの名無しさん
21/12/30 13:42:00.99 XEA11GKy.net
JavaScriptがって話ならわからんでもないが

995:デフォルトの名無しさん
21/12/30 13:49:04.54 8IVD/YcY.net
TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
フロントエンドでは気楽さと壊れやすさのトレードオフってことで受け入れるけど

996:デフォルトの名無しさん
21/12/30 13:53:13.25 XEA11GKy.net
じゃあC/C++なんかもダメだな

997:デフォルトの名無しさん
21/12/30 14:00:36.67 qk2rIpzk.net
バリデーションもできない奴がなんか言ってら

998:デフォルトの名無しさん
21/12/30 14:01:03.11 8IVD/YcY.net
そうだね
バックエンドでは実

999:質Cと大差ないちょっとだけ楽できるけど

1000:デフォルトの名無しさん
21/12/30 14:10:38.20 XEA11GKy.net
じゃあ逆にバックエンドで受け入れられる言語ってなんだろう？JavaとかRustくらい？

1001:デフォルトの名無しさん
21/12/30 14:23:51.58 8IVD/YcY.net
JavaとC#だね
型安全性がしっかりしてて実績も多い言語って言えばそれぐらいじゃないか？

1002:デフォルトの名無しさん
21/12/30 14:42:45.86 XEA11GKy.net
んー、つまり
>TS始めた時からずっと思ってたけど型が簡単に嘘を付ける言語仕様はバックエンドでは到底受け入れられんわ
JavaとC#以外の言語を触るたびに同じように思ったってことでいいのかな？

1003:デフォルトの名無しさん
21/12/30 15:01:47.81 Q5xANRZc.net
まあ、そうだね

1004:デフォルトの名無しさん
21/12/30 16:23:51.89 se0ux0qB.net
C♯やJavaよりはTypeScriptやRust選びますわ

1005:デフォルトの名無しさん
21/12/30 16:31:34.51 tab5g/QS.net
そしてバグが出ると

1006:デフォルトの名無しさん
21/12/30 16:52:28.72 XEA11GKy.net
まるでTypeScriptやRustを選ぶとバグが出るかのような物言いだが
C#やJavaを選べばバグが出ないというわけでもあるない

1007:デフォルトの名無しさん
21/12/30 17:38:29.90 tab5g/QS.net
TypeScriptは型が簡単に嘘をつけるのでバグが出やすい
型安全性がバグ削減に貢献しているのはプログラマの常識

1008:デフォルトの名無しさん
21/12/30 17:46:55.74 18t9WvJQ.net
それはあなたがバリデーション書けないからでしょ？

1009:デフォルトの名無しさん
21/12/30 17:56:31.58 XEA11GKy.net
>>967
具体的にどういうのを言っている？まさか故意にasでキャストした場合の話じゃないだろうが

1010:デフォルトの名無しさん
21/12/30 18:04:13.25 cY7zFSmj.net
その返答で書けないということが露呈したゾ

1011:デフォルトの名無しさん
21/12/30 19:17:21.94 zuTar3e4.net
>>968
型が嘘をつけることとバリデーションは別次元の話
 >>969
明示的キャストなんかしなくてもTSにはいくらでも型が嘘をつく罠がある
代表的なところだとjsonのパース、DBのI/O、api I/O、野良ライブラリのI/O、、、

1012:デフォルトの名無しさん
21/12/30 19:25:44.57 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:デフォルトの名無しさん
21/12/30 19:33:44.30 18t9WvJQ.net
>>972
いやそれはそのコードがバカじゃん……

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

1015:デフォルトの名無しさん
21/12/30 19:36:08.35 zuTar3e4.net
>>973
このコードは説明のためのスニペットだ
現実的にこんなコード書くわけないだろ
現実的には先に挙げたような状況でanyと戦わなければならない

1016:デフォルトの名無しさん
21/12/30 19:44:03.93 18t9WvJQ.net
>>971
>>975
なんの為のバリデーションとタイプガードだよ。
どこで間違った型が入りうるかなんか普通把握できるでしょうに

1017:デフォルトの名無しさん
21/12/30 19:48:28.03 pcTvcAXH.net
Javascriptのスーパーセットという最大のセールスポイントを見てなさすぎだろ
構造的部分型も便利だしany型なんて使うときには型ガードするよね
型に関してはJavaより好きだわ

1018:デフォルトの名無しさん
21/12/30 19:51:25.70 HvA/IBjD.net
Nullableを長年放置してたり文化的にも言語的にもImmutableを軽視してきたJavaもちょっと

1019:信用できないですね

1020:デフォルトの名無しさん
21/12/30 19:59:03.54 zuTar3e4.net
>>976
バリデーションってのは値が正しいかどうか検証するものであって型が嘘をついているかどうか調べるためのものじゃない
どこで型が嘘をついているか確実に判断することはむずかしい
自分達の管理するコードベースの外界とのI/Oは全て疑わしい
先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
疑わしい箇所が多すぎる
型が嘘をつかない言語なら外界とのI/Oの型定義が信用できる
信用できない領域がグッと一気に減る
だから型は嘘をついちゃいけないし
簡単に嘘をつける言語仕様は絶対におかしい

1021:デフォルトの名無しさん
21/12/30 20:05:16.00 zuTar3e4.net
>>977
構造的部分型もわかりにくいバグの温床だな
anyよりは全然マシだが
まあ楽なのは楽だよそれはわかる
ただ楽なのと安全でりかいしやすいのとは同じじゃないからね
typeは俺が言ったような真の意味で型安全を担保するための仕様
interfaceは構造的部分型でサボるための仕様
こう使い分ければよかったんだろうな

1022:デフォルトの名無しさん
21/12/30 20:09:20.24 zuTar3e4.net
>>977
セールポイントであり最大の弱点でもある
思い切って互換性切った方が絶対上手くいってた
 >>978
まあ先発の古い言語だからある程度は仕方ないね
Null安全は対応してきてる
イミュータブルは昔から使えてた(final)

1023:デフォルトの名無しさん
21/12/30 20:42:46.31 18t9WvJQ.net
>>979
型さえあってりゃどんなライブラリも安全安心だと思っているのか……

1024:デフォルトの名無しさん
21/12/30 20:51:38.40 iK2C+Pgo.net
>>982
ちゃんと読めてます？
「信用できない領域がグッと減る」って書いてあるでしょ？
型安全であれば全てが安全なんてことはない
これは常識
でも型安全ならそうでない場合に比べて大部分が安全になる
これも常識
そしてTSは一見すると型安全であるかのように見えるけれど
型が簡単に嘘をつける言語仕様のせいで実は型安全ではなく安全でない言語である
これが私の主張
よく読んでね

1025:デフォルトの名無しさん
21/12/30 21:06:33.94 18t9WvJQ.net
>>983
お、これは失敬

1026:デフォルトの名無しさん
21/12/30 21:26:07.36 XEA11GKy.net
>>971
あんたの言う「型が嘘をつく」の意味がよくわからんが。オレオレ用語じゃなくて一般的な用語で説明してくれんかな。
>先も述べたようにJsonのパース、ApiのIO、DBのIO、野良ライブラリのIO
>疑わしい箇所が多すぎる
嘘をつくもなにも、JSONはそのJSON自体の構造以上の型を主張したりはしないが。
それを勝手に別の型と見做したとしたらそのコードの方に問題があるわけだろう。

1027:デフォルトの名無しさん
21/12/30 21:31:50.13 XEA11GKy.net
>>972
ああなるほど。
型の合わせ方がわからなくてasやanyで誤魔化したらバグったってのの逆恨みか。

1028:デフォルトの名無しさん
21/12/30 21:32:15.17 yBt1j67p.net
型が嘘をつくってのは
コンパイル時に指定した型以外の値が入ってることがある
入れることが簡単にできるということ
type X = { foo: string }
function xxx(): X
例えば↑こういう定義があったとする
実際にxxx()の戻り値が文字列型のfooという属性を持っているかどうか？
それはソースコードを隅々まで読んで間違いないことを確認するまでわからない
コードはXという型はfooという文字列型の属性を持っていると主張しているわけだが実際にはそうでない場合がある
これを俺は型が嘘をついていると表現する

1029:デフォルトの名無しさん
21/12/30 21:33:00.94 yBt1j67p.net
>>986
ちげーよ

1030:デフォルトの名無しさん
21/12/30 21:36:23.80 yBt1j67p.net
JavaやC#ではこういう事は起こらない
正確には低レベルAPIでメモリを不正に書き換えれば起こせるが無理すれば起こせないこともないと言った程度
JavaやC#ではXがfooという文字列型の属性を持っていてxxxの戻り値の型がXであると書いてあったらそれを信用していい
JavaやC#は型が嘘をつかないからだ

1031:デフォルトの名無しさん
21/12/30 21:37:07.94 XEA11GKy.net
>>987
？
おめーのtscはそれコンパイルエラーにしてくれないの？

1032:デフォルトの名無しさん
21/12/30 21:39:39.80 rc2c+xCv.net
>>99

1033:0 本当に恥ずかしいからお前はもう黙ってろ

1034:デフォルトの名無しさん
21/12/30 21:39:49.15 yBt1j67p.net
>>990
しない

1035:デフォルトの名無しさん
21/12/30 21:42:03.35 18t9WvJQ.net
そんなにTSが嫌いならずっとJavaなりC♯なり使ってれば良いじゃん

1036:デフォルトの名無しさん
21/12/30 21:45:32.05 XEA11GKy.net
>>992
コンパイルエラーにならない function xxx() の例よろ。

1037:デフォルトの名無しさん
21/12/30 21:57:10.00 hxNkeOah.net
>>993
そだね
選択権があるプロジェクトなら必ずそうしてるよ

1038:デフォルトの名無しさん
21/12/30 21:59:52.63 hxNkeOah.net
>>994
function xxx(): X {
return {
foo: bugLib.getStringValueEvil();
}
}

1039:デフォルトの名無しさん
21/12/30 22:09:49.35 XEA11GKy.net
>>996
？
bugLib.getStringValueEvil() がstringと宣言されていればコンパイルが通るけどそっちが嘘だったって話？

1040:デフォルトの名無しさん
21/12/30 22:21:35.89 hxNkeOah.net
>>997
そう

1041:デフォルトの名無しさん
21/12/30 22:24:35.31 XEA11GKy.net
じゃあ bugLib.getStringValueEvil() はどうやって嘘をついたわけ？堂々巡りだが。

1042:デフォルトの名無しさん
21/12/30 22:28:29.05 hxNkeOah.net
>>999
さあどうだろうな？
だから >>987でソースコード隅々まで見たら…って書いたんだけどね
JavaやC#だったら型だけ見ればああこの戻り値のfoo属性は文字列なんだなと信頼できる
ソースコードを隅々まで見る必要はない
なぜなら型が嘘をつかないからね

1043:デフォルトの名無しさん
21/12/30 22:34:32.46 rc2c+xCv.net
anyなんかから型変換する際にランタイムチェックを追加するオプションはあっていいとは思うがTypeScriptにとってのno goalだから無いのも仕方ない
型安全性だけに拘るならTypeScriptは適当じゃないのはそれはそう(そもそもがoptional typeでしかない)
他の要素も考慮すれば個人的には悪い選択肢じゃないのでJavaScriptよりはTypeScriptを選ぶけども(C#やJavaと比較するかは目的による)

1044:デフォルトの名無しさん
21/12/30 22:38:38.66 XEA11GKy.net
ようはTypeScriptに限らず強い型付け以外全否定ってことかね

1045:デフォルトの名無しさん
21/12/30 22:56:16.20 XEA11GKy.net
次スレ立てるよ
URLﾘﾝｸ(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
ｽﾚﾘﾝｸ(tech板)
part2
ｽﾚﾘﾝｸ(tech板)
part3
ｽﾚﾘﾝｸ(tech板)

1046:デフォルトの名無しさん
21/12/30 22:57:42.38 XEA11GKy.net
TypeScript part4
ｽﾚﾘﾝｸ(tech板)

1047:デフォルトの名無しさん
21/12/30 23:01:37.83 chdQ4etC.net
>>1000
それって型指定のバグなわけで、バグを回避する為に他の言語でもソースコード全部読む必要あるのは変わらないのでは……

1048:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 1344日 1時間 13分 15秒

1049:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています