TypeScript part4 (382ﾚｽ)
上下前次1-新
1(1): 2021/12/30(木)22:57 ID:XEA11GKy(1)調 AAS
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
2chｽﾚ:tech
part2
2chｽﾚ:tech
part3
2chｽﾚ:tech
2: 2021/12/30(木)23:05 ID:18t9WvJQ(1)調 AAS
乙
3(1): 2021/12/31(金)00:30 ID:/NplslaL(1)調 AAS
>>1
乙
4(1): 2021/12/31(金)10:54 ID:jCXckXJt(1)調 AAS
4.6でmjs対応は入るのかな？
5(1): 2022/01/16(日)23:06 ID:CViIeqBQ(1)調 AAS
Unionを受け取る関数の返り値の型を引数の型によって変えたいときってどう書けばいいの？
type F<T> = (() => void) | ((x: T) => void);
const wrap = <T>(f: F<T>) => ??? ;
const a: () => void = wrap( () => {} );
const b: (x: string) => void = wrap( (x: string) => {} );
6: 2022/02/01(火)21:25 ID:RQFIXaIQ(1)調 AAS
typescript作ったやつ何考えてんだ？
tsconfigにpath alias書いた
babel.configにも書かないと動きません
webpack.condigにも書かないと動きません
jest.configにも書かないとテストできません
あのさぁ俺はビルドツール職人になりたいわけでも設定ファイル書きたいわけでもないんだよ
どうにかしてくれよほんとこのクソッタレエコシステム
7: 2022/02/01(火)23:58 ID:0JyqEM+P(1)調 AAS
typescriptはただのtype check toolです
babelはただのjavascript convert toolです
webpackはただのjavascript concat toolです
jestはただのtesting toolです
全部違うのです
吽孤javascriptを何とかマシにしたい4銃士を連れてきたよみたいなノリだからしゃーない
8: 2022/02/06(日)13:50 ID:26fWvErU(1)調 AAS
TS童貞案件がようやっと終わった。辛かった。もうやりたくない。有給とります。
@感想
・reactの時だけ使えばおk！
・鯖では使うな！どうなっても知らんぞ！
・熟練の設定ファイル職人を必ず1人雇え！絶対にだ！
9: 2022/02/06(日)14:01 ID:23zQCz2C(1/4)調 AAS
LAMPとか言ってPHPやPerlでバックエンド作ってた狂気の時代よりは遙かにいいと思うけどなぁ
10: 2022/02/06(日)14:21 ID:Fo3XpFx5(1/12)調 AAS
型バリデーションできない人には（TypeScriptは）難しい
11: 2022/02/06(日)14:32 ID:grglIiaK(1/2)調 AAS
鯖サイドは外界とのIOが多いから型バリデーションが増えすぎるのが課題かな
あとはPODの濫用が標準的なコーディングスタイルとして受け入れられてる点が問題だと感じた
これじゃ型があってても不変条件を満たしているかまではわからん
12(1): 2022/02/06(日)14:39 ID:Fo3XpFx5(2/12)調 AAS
いやPODで問題ないでしょReadonlyなりas const付ければいいじゃん
13(1): 2022/02/06(日)14:43 ID:23zQCz2C(2/4)調 AAS
PODってなんぞ？
Plain Object Darkness？
14: 2022/02/06(日)15:05 ID:Fo3XpFx5(3/12)調 AAS
型の話だしググった感じPlain Old Data型の事だと思って回答した。
プリミティブ及びプリミティブで構成されたオブジェクトからなるコンストラクタを持たないオブジェクト。ざっくり構造体みたいなオブジェクトって意味かなと。C++用語のようだ
15: 2022/02/06(日)15:19 ID:23zQCz2C(3/4)調 AAS
つまりPlatina Opal Diamond・・・ってコト！？
16(1): 2022/02/06(日)15:33 ID:grglIiaK(2/2)調 AAS
>>12
そも辺りはスケールによる
ドメインが薄いならそれでなんとかなるかもしれない
実際の業務システムはどうしてもドメインが大きくなるからちゃんとクラス化しよう
>>13
Plain Old Data
プリミティブとPODの属性だけを持っている単純な型のこと
正確にはPODと呼ぶにはC言語とのデータ互換性が要る
しかしこの文脈では緩いニュアンスで伝わると考えてPODと書いた
17(1): 2022/02/06(日)15:46 ID:Fo3XpFx5(4/12)調 AAS
>>16
『ドメインが薄い』とか何用語だ。ググっても出てこないような独自なのじゃなくて、もうちょい一般的な用語使って？
色々組み合わせるにしてもTS単独で大きなものを組むにしても入り口から出口までimmutableならそれで問題ないと思うんだけど。
デザインパターンにこだわり過ぎてない？
18(1): 2022/02/06(日)16:28 ID:d9+JDYY/(1)調 AAS
頭悪いんだよ
融通のきかない頭でっかち
19: 2022/02/06(日)16:57 ID:23zQCz2C(4/4)調 AAS
immutable な POD で FP すれば GOOD じゃん
class は not json serializable ビコーズチョベリバ
20: 2022/02/06(日)17:24 ID:Fo3XpFx5(5/12)調 AAS
無茶苦茶言ってるかと思ったらちゃんとした内容で草w
21(2): 2022/02/06(日)17:45 ID:cUJBT0A1(1)調 AAS
>>17
すまん
DDDのドメイン層を連想してくれると思って言った
イミュータブルだから大丈夫ってのは規模の小さなシステムでならたしかに間違いではない
ただ規模が大きくなるにつれてそれでは難しくなるのもまた事実
というのもイミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
なのでプログラムにバグが紛れ込みやすくなってしまう
それと特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱というのが典型的な末路だね
>>18
Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
なのでドメイン層のクラスがJson Serializableである必要はない
というかドメイン層のクラスに直接Deserializeするのは危険なので大規模案件ではむしろ禁止した方がいい
それは完全コンストラクタを経由せずにオブジェクトをインスタンス化するということであり
不正なオブジェクトを生成してしまう可能性をプログラムに埋め込むということに他ならない
22(1): 2022/02/06(日)18:34 ID:Fo3XpFx5(6/12)調 AAS
>>21
> イミュータブルなPODだと不正なイミュータブルオブジェクトの生成を抑止する方法が残念ながら無い
不正なイミュータブルオブジェクトの問題ってなに？
イミュータブルオブジェクトがイミュータブルオブジェクトにどうやって影響を与えるのさ。
> 特定の型に対する演算がプログラムのあちこちに分散してしまい凝集度が下がって大混乱
疎結合になってむしろ良いことでは？
TSにおいて凝集度はクラスで担保すべきでは無いでしょ。
23(1): 2022/02/06(日)18:49 ID:K22p1cEy(1)調 AAS
>>22
不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
その連鎖はいずれIO境界まで辿り着きユーザーに間違ったAPIレスポンスを返したりデータベースに間違ったデータを格納したりする
関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
もちろん途中でバリデーションをかけて落とすことはできるだろうがそれではバリデーションが増えすぎて手に負えなくなる
なのでそもそも間違ったオブジェクトを作れないようにしよう
作れないものを関数に渡すことはできないので安心だ
そういう考え方ね
下だけどそれを疎結合とは言わない
否定したい思いが先走って無茶苦茶言ってない？
24(1): 2022/02/06(日)19:01 ID:Fo3XpFx5(7/12)調 AAS
>>23
> 不正なイミュータブルオブジェクトを元に生成した別のイミュータブルオブジェクトもまた不正なイミュータブルオブジェクトになる可能性が高い
繰り返しになるけど、イミュータブルオブジェクトはイミュータブルオブジェクトに影響与えないよ？
> 関数の入り口に間違ったオブジェクトを渡したら関数の戻り値もまた間違ったオブジェクトになることは理解できる？
間違ったオブジェクト渡らないよ？ なんの為の型だと思ってるの？ structとか使わないの？
データの入り口（IO等）で型バリデーションすればあとは型が化けたりしないよ。
25(1): 2022/02/06(日)19:06 ID:AuLf6V7C(1/7)調 AAS
>>21
> Jsonを必要としているのは主にIOを司る層であってそれはドメイン層ではない
> 異なる層が負うべき責務を別の層が引き受けるのはクリーンな設計とは言えないよね
> なのでドメイン層のクラスがJson Serializableである必要はない
横だがこれは完全に間違ってるだろ。
シリアライズするのは確かにI/O側だが、他言語も含めて今現在は
クラス側にserialize手段を用意するのが主流だ。TS知らんがJSと同じならtoJSON()。
だからドメイン側でシリアライズする可能性のあるクラスの全てにtoJSONを用意しておくのが正しい解だという事に今はなっている。
I/O側にやらせていたのは昔の設計だ。ただそれの何が悪かったのかは俺は知らない。
（実行効率だけは無茶苦茶良かったから、クラスを導入して非効率になっただけなのかもしれんが）
26(1): 2022/02/06(日)19:18 ID:7lkHt7VO(1/9)調 AAS
>>24
つーか「影響を与える」と私が一言でも書いたかな？
君のレスでは影響を与えるって言葉を変化させるという意味で使ってるように読める
だが私はイミュータブルオブジェクトを元にイミュータブルオブジェクトを「生成する」としか書いてない
modifyとcreateはプログラミングにおいて全く異なる概念なので明確に区別することをおすすめする
PODなら間違ったデータを簡単に渡せる
IO境界だけでバリデーションすればいいという考え方は人間を信用しすぎている
人間は間違えるという前提を忘れてはいけないよ
百点満点のコードを確実に書けると確信できるようなちっぽけなシステムではそれでなんとかなるかもしれないけどね
27(1): 2022/02/06(日)19:28 ID:Fo3XpFx5(8/12)調 AAS
>>26
イミュータブルがイミュータブルなままなら問題ないって話しかしてないよ？
> 人間は間違える
そのためのTypeScriptのstructだよ？
28(1): 2022/02/06(日)19:34 ID:7lkHt7VO(2/9)調 AAS
>>25
今はなっている？ないないなってない
適当なことを言わんでくれ
JSONやXMLやバイトストリームやフォームデータのような外界の都合を吸収してシステムが扱いやすい形式に変換する(あるいはその逆の流れ)はドメイン層の仕事じゃない
それは外界とやり取りをするための専門の層の仕事だ
29(1): 2022/02/06(日)19:39 ID:7lkHt7VO(3/9)調 AAS
>>27
structだけじゃ人間は間違えるし問題あるって話をしてる
structではデータ型が合ってるところまでしか保証できない
インスタンスが抱えてるデータが満たすべき条件を満たしていることを保証できるか？そこがポイント
それを保証するにはstructでは不十分で完全コンストラクタを実装したクラスが不可欠
30(1): 2022/02/06(日)20:00 ID:Fo3XpFx5(9/12)調 AAS
>>29
だからデータの入り口で型バリデーションするんだよ。
君は前スレの最後で暴れてた型バリデーションできない人だったか。話が通じないわけだ。
31(1): 2022/02/06(日)20:04 ID:+4OSlPdc(1)調 AAS
>>30
だからそれじゃバリデーション箇所が多すぎて手が回らんっての
話がループしてるよ
32(1): 2022/02/06(日)20:06 ID:Fo3XpFx5(10/12)調 AAS
>>31
だからIOとかfetchみたいなデータの入り口だけなんだよ？
33(1): 2022/02/06(日)20:12 ID:W5e759ag(1)調 AAS
>>32
またループしてる
そこだけバリデーションしても人間のミスはカバーしきれない
規模の小さなシステムならなんとかなるかもしれないが大きなシステムでは絶対無理
これ以上は無限ループして時間の無駄っぽいね
34: 2022/02/06(日)20:14 ID:Fo3XpFx5(11/12)調 AAS
>>33
そうだね。止めてもいいよ。
35(2): 2022/02/06(日)20:51 ID:AuLf6V7C(2/7)調 AAS
>>28
toJSONを呼ぶのはI/O層の仕事で、
toJSONを定義するのはドメイン層の仕事だよ。
つか、そうじゃないと無理なんだよ。
JSONでは対応出来ない型があるから、何が入っているか分からない状態ではシリアライズは出来ない。
逆に言えば何でもシリアライズ出来れば全部I/O側に任せる事は出来るのだが、
現時点で現実的にこれはバイトストリームしかないから、バイナリデータでメモリダンプ形式で良ければ出来るけど、
これはJSONともXMLとも言わないし、実際これをやってるシステムは今は無いでしょ。
36(1): 2022/02/06(日)21:05 ID:Y8lZmwFL(1)調 AAS
>>35
ん？別の人か？
ドメイン側が提供するのは属性の読み取りアクセスと同等の引数を受け取る完全コンストラクタオーバーロードだけ
読み取った属性を外界が要求する形式に整形、シリアライズする(あるいはその逆)のはIO層の仕事
どの外界とどんな形式でやり取りするのか？
ドメイン層はそんなことは知らないし知ってはいけない
だから外界に依存しない純粋な読み取り属性とコンストラクタでIO層と連携する
IO層はそのデータをどうすべきか全て知っている
37(3): 2022/02/06(日)21:14 ID:AuLf6V7C(3/7)調 AAS
>>36
まあそれでも出来るけど、それが面倒で二度手間で意味無いからみんなPODを使ってるんだと思うぞ。
FizzBuzzEnterpriseEditionとか、君は本気でやりそうだね。
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
38: 2022/02/06(日)21:24 ID:Fo3XpFx5(12/12)調 AAS
>>37
なんだこれww
39: 2022/02/06(日)21:25 ID:7lkHt7VO(4/9)調 AAS
>>37
君も話がループしてるね
面倒だからPODで済ませるで通じるちっぽけな規模ならそれでいいんだよ私は一貫してそこは否定してないでしょ？
それなりに規模が大きくなった時の話をしてんの
FizzBuzzをエンタープライズの手法で作るのが馬鹿馬鹿しいのと同じように
エンタープライズのシステムをFizzBuzzを書くようなノリで作るのも馬鹿馬鹿しいってこと
40(1): 2022/02/06(日)21:33 ID:7lkHt7VO(5/9)調 AAS
>>35
ちなみにバイナリでシリアライズするのはprotocol buffersとか普通にあるよ
で、どんな形式で通信すんの？JSON？バイナリ？XML？CSV？
そんなのはドメイン側は知りたくない絶対に知りたくない
ドメイン側がシリアライズの責務を負ってしまったらじゃあ通信の形式が増えるたびにドメイン側を拡張するのか？
そんなのドメイン側の本質とは全く関係ない通信様式の問題なのに？
41: 2022/02/06(日)22:02 ID:AuLf6V7C(4/7)調 AAS
>>40
JavaScriptといえばJSON以外無い。
そしてXMLもDOMParserでどうにでもなる。
通信形式をドメイン側と分離するべきなのは「あらゆる形式に対応する」大前提でだ。
今時JSONかXMLしかないし、実際これで事足りるからみんなこれを使ってる。
密結合が駄目なのは「変更される可能性がある箇所」であって、何でもかんでも分離すればいいというものではない。
疎結合にすれば結局間接参照を中に挟むから、実行効率もコード効率も落ちるだけ。
Protocol Buffers見てみたが、ぶっちゃけこれ誰も使ってないだろ。
JSに対応してない時点で今現在のコンピューティングとかけ離れている。
現在もJSONで揺るぎないし、今後もJSONがさらに蔓延る雰囲気だ。
なら、ドメイン側がJSON形式に依存しても全く問題ないんだよ。
そこを無理矢理分離して、分離する意味の無いところも含めてあらゆる分離を行ってるのがFizzBuzzEnterpriseEdition。
君が言ってるのはこれ。
勿論、JSONが廃れればドメイン側のコードを書き換える必要が発生するけど、これは多分あり得ない未来なんだよ。
それでもこれに備えたければ備えるのも自由だけど.。
尚一応言っておくがJSONはJavaScriptObjectNotationの略で、つまりJSネイティブ形式だ。
だからPython等の他言語がJSON依存を避けるのならまだ分かるが、TS/JSで避ける意味はない。
君は完全にFizzBuzzEnterpriseEditionのノリでプログラミングをしてる。
42(1): 2022/02/06(日)22:16 ID:jR6D7dXS(1/3)調 AAS
PODがダメなら普通にclassを使えばいいじゃない
その class に完全コントスクラタと toJSON を実装すればいい
つか贅沢言いすぎや
TSほどJSON API と神話性高く、堅く書けて、ほどよく柔軟な言語ないで
ワイはバックエンドをGoで書かされているが、言語機能の貧弱さに発狂しそうや
爆速でコンパイルできても爆裂バグだらけじゃ話にならん
43: 2022/02/06(日)22:20 ID:jR6D7dXS(2/3)調 AAS
>>37
ヤバスギでしょ
44(1): 2022/02/06(日)22:29 ID:7lkHt7VO(6/9)調 AAS
あらゆる形式に対応するためじゃない責務を明確に分けるため
仮に変更される可能性がなければ１つの関数でシステムを組むのか？そうはならんやろ
変更される予定がなくても責務は分けて作るんだよお仕事ではね
ProtobufはgRPC
バイナリで有名なのだと他にもMessage Packとか
こっちはゲームとかfluentdで有名
君はFizzBuzzのノリでエンタープライズ開発しそうだね
45(1): 2022/02/06(日)22:30 ID:Uni4uKu0(1)調 AAS
そのDDDの文脈でTSだとバリデーションが必要で
GoやC#だとバリデーションが必要ないケースってどんな場合のこと？
46: 2022/02/06(日)22:33 ID:jR6D7dXS(3/3)調 AAS
>>45
Goは完全コンストラクタを実装できない、誰でもインタスンス作り放題ヤリ放題だからバリデーションなんかいらんのや！
バリデーションなんて軟弱フニャチンオカマ野郎がへっぴり腰を振ってるようなもんだ！
ﾌｧｯｷｭｰLGBT！
47(1): 2022/02/06(日)22:50 ID:7lkHt7VO(7/9)調 AAS
>>42
TypeScriptでもそうすれば良いじゃんってのはその通り
別にTypeScriptがclass使えないとかそういうことを問題視してるわけじゃぜんぜんないんだ
ここで最初に戻ってよくレスを読んでみて
私が提起した問題点はこれね
「PODの濫用が標準的なコーディングスタイルとして受け入れられてる」
この問題に関しては言語自体の話題じゃないんだよ
ようするに今日やったような問答をTypeScript人材を雇うと毎回全員にやらなきゃならない可能性が高いってこと
これじゃ申し訳ないけど仕事にならないよ
なので鯖サイドではTypeScriptは残念だけど人集めの段階でNGってことになるわけ
規模でかくなるのわかってるんだから最初から鯖サイドではちゃんとレイヤ分けましょうねクラス使いましょうねSOLIDなコード書きましょうねでスッと話が通じる人が多い言語で計画立てたいわけさ
そうなると古臭いけどJavaなど無難な選択肢しかないんだよな…
48(1): 2022/02/06(日)22:57 ID:AuLf6V7C(5/7)調 AAS
>>44
まあ君とは平行線のようだね。
> 仮に変更される可能性がなければ１つの関数でシステムを組むのか？
組むぞ。俺は変更される可能性がない所に依存するのは全く問題ないと見てる。
そして基本的に実行効率重視だから、無駄な事はしない。
君はドメインが「１年が365日である事を知っている必要はない」として、365すらもリテラルでは書かないのだろう。
そして人類が火星に到達した時、君のコードは無修正で動くが、俺のコードは役に立たない。
でも俺は、「一方ロシアは鉛筆を使った」は大切にすべきだと思ってるから、
365はリテラルで書いてしまって、火星に到達してから書き直す事を選択する。
俺はJSONが廃れる未来なんてないと思ってるから、コードがJSON形式に依存するのも何ら問題を感じないし、
今のJSのアーキテクチャ、つまりtoJSONを整備しろ、で全く問題ないと思ってる。
これは確かに分離出来てないアーキテクチャだけど、する意味もないと思うよ。
むしろ他言語でもJSON使えないのはポンコツ扱いだろ今は。
> gRPC
> Message Pack
> fluentd
JSONがあまり効率のいい形式ではないのは事実で、これに対する策のようだね。
ただ、俺ならI/O層でJSON形式から変換させる。
つまりドメイン層はtoJSONを定義して、それでおしまい。それ以上の形式が欲しければI/O層で変換だ。
君のアプローチより現実的だと思うけど。
49(1): 2022/02/06(日)23:02 ID:AuLf6V7C(6/7)調 AAS
>>47
そりゃお前のノリでやってくれる奴はお前の畑の奴だよ。
それがJavaならそうすればいいだけ。
ただ、PODが駄目だってのはただの先入観で、
実際それでやってる奴が多くて、それでも世界が回ってるのなら、お前が勘違いしてるだけだよ。
50(1): 2022/02/06(日)23:08 ID:7lkHt7VO(8/9)調 AAS
>>48
うん
TypeScripterとは分かり合えない人が多いだろうなとは思ってたけど君とは特に分かり合えないと思う
関数１つでシステム書く人を理解するのは私には不可能だ
365をリテラルで書かないのはDDDとかそれ以前の問題だと思うよ
君の書いたコードって四年に一回ぐらいバグ出してない？大丈夫？
処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
ライブラリ開発者が必死になって直列化コストを削減してくれたのを嘲笑うかのような所業
やっぱり理解できないや
51(1): 2022/02/06(日)23:09 ID:7lkHt7VO(9/9)調 AAS
>>49
それで回る規模の世界はそりゃ回るだろうね
これも何度も言ってるよね
52: 2022/02/06(日)23:34 ID:EROXxvgE(1)調 AAS
なら、その規模を確認してからでよかったんじゃね？
53: 2022/02/06(日)23:46 ID:AuLf6V7C(7/7)調 AAS
>>50
いずれにしてもJava出身でJava流の開発をしたいのならJavaを使うべきだよ。
シェアもJSよりはあるし、実際何とかなるだろう。
https://w3techs.com/technologies/details/pl-java
> 処理効率が大事な部分でわざわざJSONを経由して効率落とすの？
開発効率を優先するって事だよ。多分Web系の連中はこっちを選択する。
（俺はWeb系ではないが）
なおJSONも効率が悪いのは無駄にダブルクオーテーションが多いくらいだから、この方式でもさほど効率は落ちないよ。
>>51
規模に対してのアプローチが根本的に違うんだよ。
Java：どんなに大規模になってもメンテ出来るようなコードを目指す。コードはひたすらメンテ。
Web系：そもそも大規模にならないように、ひたすらマイクロサービスを目指す。コードは書き捨て。
Java流のまどろっこしいコードだとサクッと変更出来ないからこうなってるのだと思うよ。
実際、Web系だとサーバー側全コードを書き直しました、とか割と聞くでしょ。Javaではあり得ないし。
だから、Web系言語で、そんなに大規模になるという事自体が間違ったアプローチなんだよ。
そういう風に言語が出来てない。toJSONという点からも分かるだろ。
俺もこのアプローチの違いに気づいた時はちょっと驚いたけど、間違いでもないよ。
これを認められないのなら、君はJavaでやるべきだよ。
あと、依存に関する考え方も違う。
Web系で危険な依存は、死んでしまう言語/フレームワーク/ライブラリに依存する事で、
具体的にはAltJSのほぼ全部(CoffeeScript等)、Vue/React以外のフレームワーク全部とかだよ。
仮にprotocol buffersを使うとして、頓死した場合、I/O部分は書き直さないといけない。
それはドメイン側のコードをいじるのと同じ手間だと思うけど。
だったら、分離した意味って無いよね。
まあいずれにしても、君はJavaを選択すべきだと思うけど。
54: 2022/02/07(月)03:29 ID:yhez4jOW(1/12)調 AAS
あと、パフォーマンスレンジの選択も間違ってる。
スクリプト言語は、チャッチャと書いてチャッチャと動かす為の言語であって、
ゴリゴリ一生懸命コードを書いて、パフォーマンスやメンテナンス性を得るための言語ではない。
つまり、今回で言うと、
TS/JSはJSONで全く問題無い場合に使う言語であって、
JSONではパフォーマンスに問題があると分かっているのなら、GoかRustを使うべき。
勿論Javaでもいいが、RustならJavaより速い。
だからこそ逆に、手抜きして何が悪い！ってことになる。
要求仕様が「オブジェクトを復旧できること」なら、
一番簡単なのはJSONで、これを使う人が多いのは当然だ。
一々自前でコードを書きたくなければPODになる。これがいいかどうかはさておき。
(ただまあ俺も、Web系の連中はJavaのstaticおじさんを馬鹿にする割には
書いてるコードがstaticおじさんと同じなのはどうなのよ、とは思ったが)
ちなみに主張されてるようなケースでJavaならイテレータでも渡してI/O側でシリアライズするのか？
単純なイテレータだと階層があったら厳しいから、階層も跨いでいけるイテレータを渡す事になりそうだが、
それでもデータの中身が何か知ってないとシリアライズは厳しくて、
現実的に完全に分離するのは無理だと思うが。
なおメンテナンス性についてはTS/JSは以外に高い。
こういう構造にしたい、というのはあっけないほど簡単に記述出来るから、分離だけは簡単だ。
(ただ、その分離の意味があるのか？が俺には疑問なのだが)
55(1): 2022/02/07(月)03:30 ID:yhez4jOW(2/12)調 AAS
それから、規模については他の人も指摘してるけど、一体何万行のTSを書く気だ？
やれば分かるが、鯖なんて結局DBから読んで加工して吐くだけだから、
APIだけ(HTML生成無し)なら3,000行も書けばいっぱしのサービスは出来てしまう。
あっけないほど簡単にね。スクリプト言語だから記述レベルが元々高いってのもあるけど。
(HTML部分はどこまで凝るかだけど、コード自体は独立してるから分量が多くなっても何ら問題ないはず)
Javaから見ればWeb系は多分1/10位で開発してる。
Redditで6人(言語不明)、diggも6人(Go)、discordが35人(Rust)とかだったと思ったよ。
そもそもそんな「大規模開発」になってない。
この辺を知って、俺は「あれ？これはJavaのアプローチの方が間違ってたんじゃね？」と思いだしたんだよ。
OOP：どんなに大規模なコードでも取り扱ってみせる！
スクリプト言語：そもそも複雑にならない範囲に留めろ
Javaから見ればWeb系は馬鹿ばっかなのも事実だろうけど、JavaはJavaで馬鹿な事をやってる。
だから特等席を与えられていたのにJSに駆逐された。(クライアントサイドでは)
それって鉛筆でよくね？ってのを考えた方がいいと思うぜ。
56: 2022/02/07(月)06:51 ID:b69Z+ASC(1)調 AAS
TSの知識が無くTSの開発者文化に馴染めず、理解してない言葉を並べ、決して間違いを認めず、自分のやり方に固執し、目の前にある概念を理解しようともしない。
う〜んこのおっさん。
57(1): 2022/02/07(月)10:07 ID:WuDoUI67(1)調 AAS
>>55
ううむ…せめてレス読んで理解した上で応答してほしいんだが…
小さなシステムでやり方にこだわる必要はないってのは深夜3時までかけて書いた情熱的な作文でいちいち主張しなくても私も最初から認めてることでしょ？
昨日議論したのはそういう手法が通じない規模のシステムの話ね(何度もそう書いてるはずだが)
大きいシステムではうまくいかないよという話をしてるのに
その応答が小さなシステムならうまくいくから問題ないでは話が噛み合うわけがないよね
58(2): 2022/02/07(月)11:40 ID:RorkGoUL(1/8)調 AAS
いやでもわかるわ
json serializable / deserializable で、かつ this 参照可能な method 生えてれば、カプセル化というかコードの凝縮度上げられるのになとは思う
まぁそういう toJSON, fromJSON を実装すれば的な話ではあるが
type Human に getFullName 実装したい時に
POD だと getFullName(h: Human) みたいになって
getFullName(h) じゃなく
h.getFullName() みたいにしたかったのに
みたいな
59(1): 2022/02/07(月)11:50 ID:UTO8dkwM(1/11)調 AAS
凝集度をclassで確保する必要は無いんやで。
書き方についてもパイプライン演算子がstage2入ったしね
60(1): 2022/02/07(月)11:58 ID:UTO8dkwM(2/11)調 AAS
Rustのstructとimplみたく、型とそれに付随する関数を収めたモジュールを作るんや。
61(2): 2022/02/07(月)12:40 ID:yhez4jOW(3/12)調 AAS
>>57
だから何万行書くつもりなんだ？って聞いてるんだよ。
Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
鯖でやる事なんて大して無いんだよ。
セキュリティガバガバでよく、（＝社内向けシステムに表示するだけとか)
ORMまでセットアップされてれば、
fizzbuzzの次には掲示板でも作ってみようか、となるくらい単純に出来てる。
だからこそPHPみたいな糞言語が未だに主流なわけでさ。
あれほどの糞言語でも何とかなる程度に収まってんだよ。
ここら辺はやれば分かるんだが、君はやってもないのにJava的な開発を想定しているからおかしな事になってる。
だから1/10想定で、と言ってるわけでさ。
62: 2022/02/07(月)12:41 ID:yhez4jOW(4/12)調 AAS
> 大きいシステムではうまくいかないよという話をしてるのに
これが間違ってる。大きいシステムが存在しない世界なんだよ。
なぜなら、大きくなった部分は切り出され、まだ切り出されてない残り部分しか書かない方式だから。
ユーザーデータの管理が面倒です→DBとして切り出して丸投げ
HTML生成が面倒です→フレームワークに丸投げ
DBを触るのが面倒です→クエリビルダにしますか？ORMにしますか？
セッション管理も面倒です→ではこれもフレームワークで
だからフレームワークは基本的に小粒だし、場合によってはいきなり頓死する。
でもフレームワークまみれで良ければいくらでも手抜き出来る世界だし、それで良しとされてる。
そしてWeb系プログラマは基本的に技術的には非力で、これは「スクリプタをプログラマと呼ぶな」とか言われてたりするが、
だからこそ逆に、自分より上の連中が作ったフレームワークに乗っかる事に抵抗がない。
Javaの連中や、最近の初心者は、手段が目的化してしまってる。
疎結合にする事、綺麗なコードを書く事が目的になってしまってる。それは本来は手段だ。
本来の目的は、「仕様を満たすコードを最速で得る事」だよ。
その際にコードの複雑化が障害になるので疎結合や綺麗なコードが必要になるわけだが、
逆に、ひたすら切り出して絶対に複雑化させない、というアプローチをWeb系は採ってる。
OOPだと大体1,000-3,000行で各モジュールは出来、この単位で切り出して行ってるはずだが、
Web系だと本当に数行で書けるような事すら切り出してたりするし、ここまでやれば大規模化や複雑化は絶対にしない。
逆に依存性は問題になってくるから、みんな動向には敏感だろ。
どっちが良いというものでもないけど、俺はこのWeb系のやり方もありだと思うよ。
すくなくともWeb系の常識からすると、みずほ銀行のポンコツシステムとかあり得ない。
最終的には口座への入出金だけガッツリ管理出来ればいいだけなのに、何でそんなに落ちるんだよ？でしかない。
Javaの流儀でサーバー側を作るのも技術的には可能だけど、それが主流でないって事は、
Javaエンジニアなんて腐るほどいるのだし、「やらなかった」のではなく「上手く行かなかった」と考えた方が妥当だと思うけど。
それでもやるのはどうぞご自由にだが。
63(2): 2022/02/07(月)12:44 ID:NQzt3ZES(1/2)調 AAS
>>60
それが完璧にできればいいんだが、それだと大きなシステムでは統制が行き届かず、処理が分散し凝集度が下がる、というのは過去の実績から明らかなんだよね
そのスタイルでやろうとすると人間がミスをしない、という前提が必要になるんだけど、現実的にそれは難しい
なので大きい案件では「間違えるためには手間がかかる状態」を作り出して人間のミスを抑止するわけ
クラスなら処理の置き場所がはっきりしてるだけでなく、他の場所に書こうとすると別のクラスが必要になるので間違いに気付き易くなる
なので自然と処理が然るべきクラスに集まって、凝集度が高まるって話
何度も何度も言ってるけど
管理コストのスケーリングを考えなくていい、個人や小さなチームで作れる範囲なら、PODと関数でいいんじゃないかな？
その程度ならプログラマが注意深く作業すれば、ミスなく作れるからね
雑談として脱線するけど、ただデータを流すだけ的な小さいサービスは今後はノーコードが主流になると思う
鯖サイドTSのメインターゲットがそういうスモールサービスだとしたら、将来はもしかしたらノーコードとのシェア争いになるのかもね
64(1): 2022/02/07(月)12:57 ID:UTO8dkwM(3/11)調 AAS
>>63
モジュール関数がそうなる状況ではclassもそうなるよ？
65: 2022/02/07(月)12:59 ID:yhez4jOW(5/12)調 AAS
>>58
> getFullName(h) じゃなく
> h.getFullName() みたいにしたかったのに
> みたいな
それはC#で言う拡張メソッドだね。staticメソッドをインスタンスメソッドとして『記述出来る』
Goは逆にメソッドをstaticとして呼べたはずだけど。
この辺は『どう書きたいか』であり、文法の問題であって、（本来は）コード構造の問題ではない。
C#はこの辺の文法とコード構造を分離した。
つまり、メソッドとして書きたいからクラスにします、ではなく、
メソッドとして書きたければメソッドとして書ける文法（拡張メソッド）を用意した。
まあ実際はただのパッチだけどね。何故かは知らんが.NETは無駄にstaticメソッドが多くてウザイのは事実だから。
(ただ今見てみるとC#のはPODでは駄目っぽいが)
Rubyはこの辺、プリミティブなしで全部オブジェクトだから、数字にもメソッドを生やせるし、出来る素地はある。
（やってないと思うけど）
だからJSでやるならボックス化+拡張メソッドで、ということになる。
再度言うがこの辺は文法の話（に出来る話）であって、（本来は）コード構造の話ではないよ。
66(1): 2022/02/07(月)13:01 ID:NQzt3ZES(2/2)調 AAS
>>61
業務システムは何万行の単位じゃ足りない
そこから1桁2桁は増える
君が幸運にも高々数千行の平和なシステムとしか縁がない環境にいるのはよくわかったよ
でも世の中のシステムはそんな恵まれたももばかりじゃないんだ
企業の業務がどれだけ複雑で巨大なのか想像してみたことある？
適当にそれなりの規模の企業をピックアップしてどんな仕事してるか想像して見て？
データベースやIOや画面とか全部取っ払ってドメインロジックだけでいいよ
それを君は3000行ぽっちで実装できるのかい？
もしできるというなら今すぐにそのシステムを売り込みに行った方がいい
あっという間に大金持ちだ
67(1): 2022/02/07(月)13:05 ID:RorkGoUL(2/8)調 AAS
>>59
パイプ何年かかっとんねん
パイプ待ってる内にシステムサ終ですわ
object の後のドットで補完できると絶頂射精できるんや
パイプなんてどうやっても補完できないし無理無理かたつむり
68: 2022/02/07(月)13:13 ID:wsXwvKB4(1)調 AAS
>>64
頻度の話ね
69(1): 2022/02/07(月)13:18 ID:UTO8dkwM(4/11)調 AAS
>>67
そういう事なら仕方ないなw
可変長パイプ関数TSで作るのは確かに辛いけど、とりあえずこんなんで良くね？
https://stackoverflow.com/questions/65154695/typescript-types-for-a-pipe-function
70(1): 2022/02/07(月)13:29 ID:yhez4jOW(6/12)調 AAS
>>66
> 業務システムは何万行の単位じゃ足りない
それは仕様を絞り込めてない糞だからだよ。
既に言ったとおり、銀行のシステムなんて最終的には「口座への入出金管理」でしかないだろ。
だったらそれをまず作って、これが3,000行。
そしてそれが株からなら、株を管理する鯖を立てて、これも3,000行。
オンラインバンキングが欲しければ、これもUI専用鯖を立てて3,000行。とやっていくのがマイクロサービス流。
モノリシックには作らないから、でかくなりようがない。
この辺は発想の違いで、以下が分かりやすいが、
https://note.com/tsuchie88/n/ncae14ac6466b
SMBCがマイクロサービス的で、君が見てる世界は三菱UFJのモノリシック型だね。
どっちが良いとかいう単純な話でもないのだけど。
まあいずれにしてもやりたいようにやればいいとは思うよ。
俺はそれは「誰も思いつかなかった」のではなく、「既に失敗してるから今は誰もやってない」だけだと思うけど。
文化の形成過程って、これだと思うし。
文化を否定する前に、まず何故そんな文化になってるのかを考えるべきだよ。
それは何だかんだで現時点での最適化がかかった状態ではあるのだから。
>>63
フレームワークをこねくり回すだけで出来るものはノーコードが主流になるとは思う。
ただしそれでWeb系言語が廃れる事はない。フレームワークになってない部分は自前で書くしかないので。
なお主にマイクロサービスを目指しているのはGoだね。みんなRustに行っちゃった感はあるけど。
TSは…JSだと型が無くて糞だと思ってる連中が使ってるはずだけど、何指向かは知らん。
（というか俺はTS使ってないし)
71: 2022/02/07(月)13:33 ID:Afq51Jp9(1)調 AAS
業務システムにオープン系入ってきてもう何十年よ
プロジェクト規模ならわかるがシステム規模で何十万行とか
ミドルウェアも活用できてない失敗プロジェクト
DSLで品質も保ててスッキリ記述できる部分も汎用言語で書いてそう
72(1): 2022/02/07(月)13:36 ID:Ipfs3xdV(1)調 AAS
>>70
ははは
ならその素晴らしい数千行の銀行システムを売り込んできたら？
73(1): 2022/02/07(月)13:40 ID:UTO8dkwM(5/11)調 AAS
途中までの思想はわかるけど、数千行銀行はちょっと無理だと思うよ……
74: 2022/02/07(月)13:46 ID:UTO8dkwM(6/11)調 AAS
とはいえ分割単位次第か
75(2): 2022/02/07(月)13:58 ID:yhez4jOW(7/12)調 AAS
>>72
今は俺はJavaを殺すのはWeb系だと思ってるよ。
何処かが「もうこれWeb系でよくね？」として試しにやってみて成功したら、一気に流れると思う。
開発/運用コストが1/10〜1/100だろうから、
金銭面しか評価出来ない文系馬鹿が仕切ってる日本の銀行とかは一気に導入だよ。
マジな話、みずほ銀行が作り直すのならマイクロサービスでやれば面白いとは思ってる。
まあ現実的には病院や自治体から導入で、銀行は最後尾だろうけどね。
>>73
それは発想の方向の違い。
単発サービスで3,000行程度に留まるところまでサービスを分割する。
できるできないではなく、3,000行程度になるまでひたすら分割するだけ。
実際、DBに対して単に読み書きするだけなら、200行程度で書けるでしょ。
だから最悪、1,000行程度までのマイクロサービスに分割しろ、と言われても普通に出来てしまうんだよ。
76: 2022/02/07(月)14:09 ID:UTO8dkwM(7/11)調 AAS
>>75
そういう意味なら納得です
77(1): 2022/02/07(月)14:10 ID:4z8oj16v(1)調 AAS
素晴らしい！
ひとりの天才の出現によって金融系システム従事者が超難度システムのメンテから解放されるんだね
私はもしかすると時代の転換点を最も近いところから目撃してしまったのかもしれない
78(1): 2022/02/07(月)14:19 ID:RorkGoUL(3/8)調 AAS
>>69
lodash compose かな
まぁあれはあれで前立腺イキな気持ちよさはある
79: 2022/02/07(月)14:20 ID:RorkGoUL(4/8)調 AAS
>>77
みずほ社員２０万人「ﾀｽｹﾃ・・・ﾀｽｹﾃ・・・」
80(1): 2022/02/07(月)14:27 ID:mmIvHtEJ(1)調 AAS
ちゅーかなんでみんながみんなクソデカカチカチシステム作る前提なわけ？
適材適所って言葉を知らんのか
81: 2022/02/07(月)14:43 ID:UTO8dkwM(8/11)調 AAS
>>78
lodash有りならlodash/fpにそのままズバリpipeもあるし、部分適用もお手の物やん
82(1): 2022/02/07(月)14:51 ID:RorkGoUL(5/8)調 AAS
>>80
だって小さいシステムなら誰でも作れるじゃん
それこそPHPやPerlでも構わな・・・くはない死にたくなるけど、まぁやってやれんことはない
っぱエンジニアは20万人月回してこそ1人前でしょ
83(1): 2022/02/07(月)14:55 ID:R1s+yfGI(1)調 AAS
それにしてもマイクロサービス万能論者って久々に見た気がするわ
サービスを分割すればするほどサービス間の連動の管理が難しくなってそれはそれでうまくいかないぞ
というんでモジュラーモノリスだとか色々回帰論が出てきて今となっては「やっぱり銀の弾丸はなかったね」が常識で通じる時代になったと思ったんだが…
仮に30万行のシステムがあったとしてそれを3000行に分割したら単純計算で100個に分割できるわけだ
100種類のサービスを間違いなく連動させるのがどれだけ大変なことなのか
ちょっと甘く見過ぎてる感じがするね？
84: 2022/02/07(月)15:01 ID:dHoIQX/o(1)調 AAS
>>61
>Webの場合は3層なりに強制的に分割されるし、状態管理はDBに丸投げ、View/UIはHTML/CSS/JSに丸投げなので、
>鯖でやる事なんて大して無いんだよ。
どんだけ無知なんだよww
流石にこのレベルで偉そうに語られると相手するのが恥ずかしくなる
85: 2022/02/07(月)15:02 ID:HmGAn9CY(1)調 AAS
>>82
TS開発者全てを20万人月扱うスーパーマンにするなw
86: 2022/02/07(月)15:13 ID:27SiZacg(1)調 AAS
>>75
相手がボロ出すまで同じ事繰り返すだけの自演おじさんなんて相手しなくて良いよ。おじさんの話の内容見てても読解力もTS理解度も足りてないんだし
87(1): 2022/02/07(月)15:26 ID:S/gDVAW3(1/2)調 AAS
DDD的な話はわりとまともなこと言ってるけど
コード例を出さないからTS固有の問題なのか使い方や作り方の問題なのか判別つかないね
88: 2022/02/07(月)15:33 ID:S/gDVAW3(2/2)調 AAS
銀行みたいに堅牢性や永続性が最重要のシステムをTSで作るわけないけど
変化に対する柔軟性に重きを置くシステムならサーバー側でもTSは有力な選択肢だと思う
UnionやIntersectionのおかげでFunctionalなDDDがやりやすいってのが一番の理由
JavaみたいにOOPベースのDDDやるならTSを選ぶメリット感じない
89: 2022/02/07(月)16:02 ID:UTO8dkwM(9/11)調 AAS
>>87
それだよねぇ。長い文章書くわりに具体的な内容無いもの
90: 2022/02/07(月)16:15 ID:yhez4jOW(8/12)調 AAS
>>83
> 30万行のシステム
これがそもそも間違いなんだよ。
銀行なんて最終的には通帳に記入する内容、つまりは「日時と金額と取引相手」だけ管理出来てればいいんだぞ。
最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。
無駄に膨らんでる理由は、過去のコードを除去出来ない点にある。
だけどそれは新規に書く部分には関係ない。
だから現実的には携帯みたいに2G->3G->4G->5Gと徐々に載せ替え、過去の口座も徐々に新鯖に載せ替えて、
古いコードは丸ごと捨てていけば良かっただけの話。
「メンテする」というのがかなり難しいから、「新規に書いて古いのは捨てる」の発想。
実際Web系はこれに近いでしょ。
実は本来はOOPもこれ（モジュール単位で入れ替えてアップグレードしていく）だったのだが、
何故かひたすらメンテする思想になってしまってるが。
一応言っておくが俺が言ってる行数は、71の言ってる「システム規模」、つまり自前で書くコード規模な。
3rdパーティのライブラリやフレームワーク等、他人が書いてて既に動くことが確定しているコードは含まない。
まあこれを誤解しているレスは今のところ無いと見ているが。
91: 2022/02/07(月)16:16 ID:yhez4jOW(9/12)調 AAS
あと俺は別にマイクロサービスが良いと思っているわけではない。
俺が言ってるのは、（という程は言ってないが）
「コードを書いて捨てる前提なら、メンテナンス性も可読性も必要ない」って事だ。
ここが逆転の発想なんだよ。
元々これらが必要だったのは、
初心者あるあるの「半年前に自分が書いたコードが読めない」「規模が大きすぎてコードを追えない」を回避するためだ。
後者については大体10,000行程度が限界だと昔から言われてるから、単純には、
・半年で開発を終了出来ない規模以上の開発は、可読性が高いコードでないと無理。
・10,000行を越える規模の開発は、一人では無理。よって他人にも読めるコードを書け。
・作り直すにしてもどうせ同じようなコードを書く事になるから、メンテした方が生産性が高い。
というわけでこれが大正義とされていたわけだが、実際は、
・そもそも可読性の高さなんて初心者には分からない。
・メンテ性を上げるために間接参照挟みまくってるコードは、余計に分かりにくくなる。
・Web系はそもそもそんなに大規模にならない。(DBとJSに切り出した時点でほぼスカスカ）
・Web系は仕様自体がガンガン追加されるので、古いコードをありがたがってメンテする意味がない。
（新しい仕様を使った機能は新しく書くしかない）
なので、「依存しない」ではなく「依存先を適切に選んで単純なコードを書き、ハズレだったら捨てる」と割り切ってるのがWeb系。
具体的にはJSONもそうだろ。toJSONはJSON形式に依存する大前提で、JSON形式が捨てられれば立ちゆかなくなるコードだ。
しかし、JSONが使える限りは至極単純なコード、JSON.stringifyとJSON.parseで終われる。
そこを完全コンストラクタを呼び出すコードを全クラス分I/O層に置け、というのは、理屈は分かるが、無駄手間でしかない。
それがJavaにおいては正義だ、というのもまた事実なのだろうけど。
でも実際それがJava界隈の糞な所でもあるよね。
関数ポインタが使えないという言語の問題を継承をこねくり回したデザインパターンで誤魔化して糞コードにしてて、
しかもそれを自覚出来てないところとかもね。
92: 2022/02/07(月)16:17 ID:yhez4jOW(10/12)調 AAS
だから他人から言われた大正義を信じるのではなくて、それは何の為なのか、
どこまで依存していいのか、何に依存してはいけないのか、
コードはどの程度メンテする予定で、可読性はどれくらい必要なのか、
ちゃんと自分で考えて丁度良い点を目指さないと駄目なんだよ。
Javaにおいては20年後に他人がコードを読む前提だから、間違ってもこんな事は言われないはずだけど、
Web系においては、20年後も動いているコードなんて存在しない前提でも全く問題ないんだよ。
だからJavaの常識はJavaの世界向けにチューニング済みであって、それをWeb系に持ち込んでも失敗するだけだよ。
まあそれでもやるのは自由だけど。
93(1): 2022/02/07(月)17:00 ID:RorkGoUL(6/8)調 AAS
> 最初から綺麗に作れば、何をどうやっても30万行なんてならんよ。
ガラパゴス日本村のおらが法のスパゲッティをシステム化するんだからしゃーない
30万のif文がおんどれらを襲う
この国の映し鏡である金融システムをリファクタするには、まず老い腐った政治家どもを晒し首にして
もう一度ﾄｷｮを焼け野原にするところからやり直さなきゃいけないんだよ
94(1): 2022/02/07(月)17:13 ID:UTO8dkwM(10/11)調 AAS
>>93
おまいさん以前Linux板あたりに居なかったか？
95(1): 2022/02/07(月)18:19 ID:RorkGoUL(7/8)調 AAS
>>94
いたよ。あそこは楽しかったね。
96: 2022/02/07(月)18:34 ID:UTO8dkwM(11/11)調 AAS
>>95
だな。相変わらずで何よりだ
97(1): 2022/02/07(月)21:20 ID:yhez4jOW(11/12)調 AAS
>>58
そういえば
> fromJSON
ではなくて、reviver関数な。
https://developer.mozilla.org/ja/docs/Web/JavaScript/Reference/Global_Objects/JSON/parse
> getFullName(h) じゃなく
> h.getFullName() みたいにしたかったのに
> みたいな
あと、出来る/出来ないで言えば、これは出来るよ。勿論禁じ手だが
Object.prototype.getFullName = function(){return this.firstName+this.familyName;};
var h = {firstName:'Java', familyName:'Script'};
h.getFullName(); // "JavaScript"
とか。問題は、JSはこれを行うように設計されてるのに、事実上使えない点で、
プロトタイプ拡張がもうちょっとローカルに出来る仕組みが導入されたら言語としては面白くなるとは思うよ。
(俺は知らないけど、)prototype.js時代は楽しかっただろうとも想像出来る。
それぞれのclassをちゃんと整備する方が正道ではあるのだけどね。
98: 2022/02/07(月)21:40 ID:yhez4jOW(12/12)調 AAS
一応訂正。enumerableとwritable消しときます。
Object.defineProperty(Object.prototype,'getFullName',{value:function(){return this.firstName+this.familyName;}, configurable:true});
99: 2022/02/07(月)21:51 ID:RorkGoUL(8/8)調 AAS
>>97
へー、reviver初めて知ったわ、サンガツ
いやープロトタイプ汚染なんて30年ぶりに思い出したよ
Goのレシーバをsyntax砂糖で自動でmethod生えるような文法の方がいいと思う
100(3): 2022/03/05(土)02:42 ID:DdhkyzyV(1)調 AAS
https://twitter.com/uhyo_/status/1499759388462297096
uhyo_の上から目線が年々悪化している
発表でも口調からそれが感じられる
相手を思いやらずくさすハラスメント人間がTwitterのTSコミュニティ作ってるのは最早害悪では
会社のSlackでこんなのやられたら何人か辞めるでしょw
https://twitter.com/5chan_nel (5ch newer account)
上下前次1-新書関写板覧索設栞歴
あと 282 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s