TypeScript part2 [転載禁止]©2ch.net

**デフォルトの名無しさん** · 2015/04/30(木) 18:37:29.98

http://www.typescriptlang.org/

TypeScript lets you write JavaScript the way you really want to.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

前スレ
http://peace.2ch.net/test/read.cgi/tech/1349187527/

**デフォルトの名無しさん** · 2016/05/14(土) 11:35:56.64

そもそも別物なのに同じ挙動をすると期待するのが間違い

**デフォルトの名無しさん** · 2016/05/14(土) 11:46:02.57

XPでもジャンクション使えたけど
MSの態度が曖昧でどうしたいのかわからなかった

Vista でこの辺のファイルリンクとか代替ストリームとか正式サポートされた

**デフォルトの名無しさん** · 2016/05/16(月) 19:25:09.47

>>355
XPの時はフォルダのハードリンクは作れたよ。今は知らん
Linuxはフォルダ(ディレクトリ)のハードリンクはroot権限が必要になるな
OS問わずにフォルダのハードリンクは危険ってことだ
XPはシンボリックリンクが無くてハードリンクのみだから罠に嵌められた
Vista以降はシンボリックリンクが使えるからそっちは特に問題はないはず

**デフォルトの名無しさん** · 2016/05/16(月) 21:06:35.83

XPの時はフォルダのハードリンクは作れん。XP現役で使っている。
異なるドライブでも可能なジャンクションならできる。

**デフォルトの名無しさん** · 2016/05/17(火) 11:18:29.53

>>359
もれも 358 はパーティションをフォルダにリンクする話と間違ってるなーと思ってみてた

**デフォルトの名無しさん** · 2016/05/17(火) 11:19:25.01

リンクっつーよりマウントだな

**デフォルトの名無しさん** · 2016/05/17(火) 13:37:15.22

358だけど何らかのコマンドでリンクを作成したのは間違いないが
調べてみるとlinkd.exeの可能性が高い
要するにジャンクションって事か？
なにぶんXP使ってたのはかなり昔の事なんで記憶が曖昧だったよ

**デフォルトの名無しさん** · 2016/05/17(火) 13:54:39.38

Linuxでもディレクトリのハードリンクはできなかったはず。
http://unix.stackexchange.com/questions/22394/why-are-hard-links-to-directories-not-allowed-in-unix-linux
>>358 のroot権限うんぬんは、Solaris限定かもしれない。

Windowsでも記事がある。今ならmklinkだけでいい。昔はfsutilなりlinkdなりもあった。
http://www.atmarkit.co.jp/ait/articles/1306/07/news111.html
フォルダのハードリンクはできないから >>353 も用語違い。
まぁ、ジャンクション+ごみ箱が多くの不幸な事故を生み出したのはその通りだが。

**デフォルトの名無しさん** · 2016/05/17(火) 14:37:13.73

そんな事より元々の質問の答えは無いの？
俺も知りたい。共通ライブラリ化出来ないと不便だよな。

**デフォルトの名無しさん** · 2016/05/17(火) 15:17:02.05

そんな事より元々の質問をVisual Studio 2015のスレで聞け。
簡単な回答は >>344 >>352 で既出。

VS2015のUIだとファイルのコピーが作られるのが問題なのだろうが
*.csproj を直接テキスト編集すれば上位フォルダのパスも扱えるようには見える。
Include="..\xxx"

**デフォルトの名無しさん** · 2016/05/31(火) 14:00:10.58

windows10でtypescriptやるには何をインストールすればいいのさ？

**デフォルトの名無しさん** · 2016/05/31(火) 14:31:56.32

知らないものを始めたいときは、とりあえず「○○ 入門」でぐぐれ

**デフォルトの名無しさん** · 2016/06/01(水) 22:34:33.37

ms謹製なので、msのツールが使えそう

**デフォルトの名無しさん** · 2016/06/04(土) 18:08:24.21

VSで作っているけど
#region
#endregion
的な物ない？

**デフォルトの名無しさん** · 2016/06/04(土) 19:51:23.66

>>369
無い

**デフォルトの名無しさん** · 2016/06/04(土) 21:45:06.08

>>370
ありがとうございます！

**369** · 2016/06/04(土) 22:49:04.19

>>371
お前誰？

**デフォルトの名無しさん** · 2016/06/04(土) 22:49:50.74

>>370
ないんですね
ありがとうございます

**デフォルトの名無しさん** · 2016/06/04(土) 23:36:31.88

>>369
Proposal: Preprocessor Directives
https://github.com/Microsoft/TypeScript/issues/4691

プリプロセスの提案はあるよ
でもこれに限らず、C#にある仕様だからといって優先的に取り組む感じはしないかな
節度を持ってJS文化に適合させていきたいのかもね

**デフォルトの名無しさん** · 2016/06/04(土) 23:55:44.04

プリプロセスなんてコンパイラだからこその機能なのにTypeScriptの設計者は
若干偏屈なところがあるよな
abstractは導入しといてvirtual,overrideがいらねーとか意味が分からん

**デフォルトの名無しさん** · 2016/06/05(日) 18:43:32.96

色々入れすぎるとまたアンチM$(笑)から叩かれそう

**デフォルトの名無しさん** · 2016/06/10(金) 22:29:38.27

>>375
overrideは入りうるよ
一度は断ったけど、最近になって再検討して受け入れることにしたようだ

Support override keyword on class methods
https://github.com/Microsoft/TypeScript/issues/2000

**デフォルトの名無しさん** · 2016/06/10(金) 22:52:16.31

>>377
お、375じゃないけど超うれしい

**デフォルトの名無しさん** · 2016/06/16(木) 19:04:16.91

The Future of Declaration Files
https://blogs.msdn.microsoft.com/typescript/2016/06/15/the-future-of-declaration-files/

関連
npmでTypeScriptの型定義を管理できるtypesパッケージについて
http://qiita.com/laco0416/items/ed1aadf335f12cd3618d

**デフォルトの名無しさん** · 2016/07/15(金) 00:06:52.35

Announcing TypeScript 2.0 Beta
https://blogs.msdn.microsoft.com/typescript/2016/07/11/announcing-typescript-2-0-beta/

TypeScript 2.0 Beta 変更点
http://qiita.com/vvakame/items/ae239f3d6f6f08f7c719

**デフォルトの名無しさん** · 2016/07/15(金) 00:10:10.35

15K行のアプリをTypeScript1.8から2.0に移行してみた
http://rhysd.hatenablog.com/entry/2016/07/15/090000

**デフォルトの名無しさん** · 2016/07/17(日) 11:23:12.55

ES3対応ってまだいるの？

**デフォルトの名無しさん** · 2016/07/18(月) 16:13:28.10

https://github.com/showcases/programming-languages

TypeScript　　★13,201
CoffeeScript　★13,152

遂にGithubスター数がCoffeeScriptを超えた

**デフォルトの名無しさん** · 2016/07/19(火) 12:58:14.30

比べる事に意味があるとは思えんがな…
CoffeeScriptはAltJSでTypeScriptはBetterJSだ
JavaScriptが嫌いな人はCoffeeScriptを使えばいいんだ

**デフォルトの名無しさん** · 2016/07/24(日) 15:50:35.09

Intellij IDEAでTS開発捗りすぎワロリンヌ

**デフォルトの名無しさん** · 2016/07/26(火) 06:50:53.34

JavaScriptとTypeScriptの関係は
C言語とJavaの関係に似ている様な気がする

**デフォルトの名無しさん** · 2016/07/26(火) 07:58:39.74

>>386
だから何よ？

**デフォルトの名無しさん** · 2016/07/26(火) 15:46:52.18

プロトタイプベースは人類には早すぎたんだ
クラスベースでないと万人には理解できない

**デフォルトの名無しさん** · 2016/07/26(火) 16:29:48.15

プロトタイプベースは既存のインスタンスから継承できる先進的な機能ではあるが
そもそも他の言語では隠されてる継承の仕組みがむき出しになってるだけなんで
無理に使う必要もない
クラスを作るイディオムとか普通にclassを使えばいいんだ

**デフォルトの名無しさん** · 2016/07/27(水) 06:57:54.53

>>387
歴史は繰り返す

**デフォルトの名無しさん** · 2016/07/27(水) 13:58:29.20

WebAssemblyは当面C++のゲーム用だけどDOMもいじれるようになる予定だから
そうなるとまたWeb用言語の勢力図は変わるかもしれないな
Webの世界に安定は無い

**デフォルトの名無しさん** · 2016/07/27(水) 14:22:46.06

デバッガが当分クソそうだけどWebKitはそのうち充実させて生JS殺しにきそう

**デフォルトの名無しさん** · 2016/07/27(水) 23:47:21.54

>>386
CとC++じゃね
統一言語の上位互換で、元々はトランスパイラだし

**デフォルトの名無しさん** · 2016/07/28(木) 06:25:04.12

FunScriptでもやるか

**デフォルトの名無しさん** · 2016/07/28(木) 19:15:17.96

>>393
LLVMじゃね

**デフォルトの名無しさん** · 2016/07/29(金) 10:57:47.10

2.0のstrictNullChecksへの対応は結構キツイなぁ
「フィールドAがあれば、フィールドBも必ずある」ような暗黙ルールを咎められる

「変数?」が「型 | undefined」の扱いになるから
無効な値にはnullを使わずundefinedで統一したほうが良さそうだ

構文としては、返値、ローカル変数、末尾以外の引数にundefinedを許したい場合
いちいち「| undefined」が必要になる。Swiftのように ? は型の側が良い気がするんだが

**デフォルトの名無しさん** · 2016/07/29(金) 14:56:44.05

undefinedはプロパティそのものが存在しないことを表すんだからプロパティ側に?付けるのは自然でしょ
2.0は個人的にはかなり好きだな
最近の新言語といえばWeb系のノリで適当に作られてるのが多い中、これほど思想が明確で一貫した言語は珍しい

**デフォルトの名無しさん** · 2016/07/29(金) 16:06:58.19

「存在しない」と「undefinedを保持している」の2つの意味があるからなぁ
前者ならプロパティの属性、後者なら型の属性に解釈できるように感じる

strictNullChecksは簡単には対応できなかったが
noImplicitThis, noUnusedLocals, noUnusedParameters は
影響が少ないわりにバグを拾ってくれてありがたかった

**デフォルトの名無しさん** · 2016/07/29(金) 23:41:16.66

>>398
JavaScriptはundefineって言われても本当にundefinedなのか意図的に設定したundefinedか判別不能だから
nullとundefinedを区別する意味があるけど、TypeScriptの場合は「存在しない」なんて有り得ないからnullは要らない子だし
undefinedの場合は意図的に設定したと分かる

**デフォルトの名無しさん** · 2016/07/30(土) 00:18:48.03

ノードの有無のチェックは存在を確認するし番兵は一般的にnullを使う
前者はプロパティで後者は型だろう

**デフォルトの名無しさん** · 2016/07/30(土) 08:46:23.50

F#「あなたはヌルチェックでどれほど人生を無駄使いしているかを知るべきである」

**デフォルトの名無しさん** · 2016/07/30(土) 13:20:14.13

===を使えば全部解決

**デフォルトの名無しさん** · 2016/07/30(土) 23:28:44.49

"型?" については "| null"、"| undefined"、その両方の
どれにすべきかで議論がまとまらなかったみたいだ
しばらくは採用されないだろう

https://github.com/Microsoft/TypeScript/issues/7426
https://github.com/Microsoft/TypeScript/issues/7488

**デフォルトの名無しさん** · 2016/08/01(月) 14:04:09.45

>>400
DOMとかWebGLとか普通にnullを返すからどうしてもnullを使わないといけない場面は出てくる
けど、TypeScriptだけの処理の場合はnullを使う意味は全く無いな
本家のコーディングスタイルにもnullじゃなくundefinedを使えと書いてある

**デフォルトの名無しさん** · 2016/08/01(月) 18:46:01.78

JavaScriptの根幹にある設計ミスだからな
トランスパイラの層ではその尻を拭うのも難しかろう

**デフォルトの名無しさん** · 2016/08/01(月) 19:32:59.87

>>404
知ってるけど命令型アルゴリズムを書くときにわざわざnullをundefinedに置換するほどのメリットもない
教科書通りnull使ったほうが思考のオーバーヘッドがなくて楽
どちらでもいい時はundefinedに寄せる

**デフォルトの名無しさん** · 2016/08/01(月) 22:13:22.57

Suggestion: Extension methods
https://github.com/Microsoft/TypeScript/issues/9

初期から提案のあった拡張メソッドだが、不採用が決まった

**デフォルトの名無しさん** · 2016/08/02(火) 00:27:46.69

型の有無で動作が変わるのはTypeScriptの設計思想からして不適切

**デフォルトの名無しさん** · 2016/08/02(火) 12:10:13.85

クラス定義には含まれないプロパティをインスタンスが持てる言語で
そもそも拡張メソッドが成り立つものなのかね？
Java interfaceのdefaultメソッドのほうがまだ芽がある気がするが

**デフォルトの名無しさん** · 2016/08/02(火) 17:21:45.08

>>406
教科書って何だよ
俺たちの教科書はTypeScript公式のドキュメントだけだ

**デフォルトの名無しさん** · 2016/08/02(火) 18:37:46.13

>>410
アルゴリズムの本じゃね？

**デフォルトの名無しさん** · 2016/08/03(水) 00:12:57.56

nullかどうか判定するのに
hoge === null
とかやってないよな？
!hoge
で統一すればundefinedのみで何の問題も無い

**デフォルトの名無しさん** · 2016/08/03(水) 01:16:56.62

これはひどい釣り

**デフォルトの名無しさん** · 2016/08/03(水) 08:01:27.31

数値と文字が渡されないケースなら ! でも良い
渡されるなら == null (2個) を使う

TSLintの設定で、比較で null を使うのは許して、値としては許さないのが欲しいな

**デフォルトの名無しさん** · 2016/08/03(水) 12:08:49.21

null汚染

**デフォルトの名無しさん** · 2016/08/03(水) 14:40:42.74

>>413
お前がど素人なのはわかったよｗ

**デフォルトの名無しさん** · 2016/08/03(水) 17:20:15.41

>>413,414とかってnumberな変数にnullとか代入しちゃってんだろうな…
そりゃstrictNullChecksで困るわけだ

**デフォルトの名無しさん** · 2016/08/03(水) 21:04:30.24

入れるわけねーだろバカ

**デフォルトの名無しさん** · 2016/08/03(水) 22:55:31.78

皆さん結局nullとundefinedを区別しているの？どんなコードを書いているの？

**デフォルトの名無しさん** · 2016/08/03(水) 23:55:39.77

一つの変数で区別する用途を無理やり考えるならば
・undefined: 初期化前
・null: 利用不可
・object: 利用可
なんて例があるかもしれない。普通はNullObjectで済ませるか

**デフォルトの名無しさん** · 2016/08/04(木) 02:41:29.69

>>418
じゃあif(!hoge)の判定がTypeScript的には何も問題無いことは分かるよな？
どの辺が釣りなのか教えてくれ

**デフォルトの名無しさん** · 2016/08/04(木) 09:59:24.73

strictNullChecksを気持ちよく使いたいなら構造から見直しになるな
{ x?, y? } // 必ずペアで使う
ではなく
{ pt?: { x, y } }
としないと ! を避けられない

**デフォルトの名無しさん** · 2016/08/08(月) 22:15:39.27

だれかtypeScriptでバリバリサーバサイドもやってるぜって人いる？
使い勝手を是非聞きたい

**デフォルトの名無しさん** · 2016/08/25(木) 22:38:44.02

マクロのミスでconst enum同士で除算しちゃってて間違い探しをする羽目になったぜ
ありえない数値になってたのにコンパイラは叱ってくれなかったよ

**デフォルトの名無しさん** · 2016/08/26(金) 07:44:50.99

>>424
enum同士の除算結果の型はnumberだから、コンパイラの解釈は妥当だぞ

「単位付き数値」があればエラーにできるケースもあるかもしれない
Nominal typesの一環で良い感じの機能が入らないものか

**デフォルトの名無しさん** · 2016/08/26(金) 10:18:15.73

numberからconst enumへ暗黙的な変換が許されるのが問題だと思ったんよ
警告されれば先に気づくことができたから

**デフォルトの名無しさん** · 2016/08/26(金) 15:52:13.72

暗黙も何もenumの要素は最初からただのnumberだからな
JavaScriptとの互換性を考えれば妥当な仕様だろう

**デフォルトの名無しさん** · 2016/08/26(金) 16:16:08.43

他言語と比べると確かにチェックがガバガバだが
interfaceを明示的にimplementsしなくてもシグニチャだけを見ることと比べると
一貫性はあるとは思う。型システムがStructuralなことの弊害だろう

数値でなくても良いなら enum より String Literal Types を使うべきなんだろうな

**デフォルトの名無しさん** · 2016/08/26(金) 16:48:05.33

型システム自体はJavaScript側にあるんだ
TypeScriptがやってる事はJavaScriptのソースに書かれてる型を見えるようにしてるだけとも言える

そもそもJavaScriptが動的型なんだから無理やり静的型にしようとしても微妙なところは出てくるだろうな

**デフォルトの名無しさん** · 2016/09/01(木) 04:24:05.73

Announcing TypeScript 2.0 RC
https://blogs.msdn.microsoft.com/typescript/2016/08/30/announcing-typescript-2-0-rc/

>>380に追加
Number, enum, and boolean literal types
https://github.com/Microsoft/TypeScript/pull/9407

**デフォルトの名無しさん** · 2016/09/02(金) 02:34:58.82

switch使うとダサくなるな
match withにして欲しい

**デフォルトの名無しさん** · 2016/09/02(金) 15:48:27.54

内部モジュールについて教えてください。
これを使う場合ってconcatで1ファイル化する場合ってことでいいんでしょうか
webpackをつかって1ファイル化する予定なんですがその場合は外部モジュールを使う認識であっていますか？

**デフォルトの名無しさん** · 2016/09/02(金) 17:23:11.44

外部モジュールになるファイルは独立してるはず
今はnamespace推奨で内部モジュールって表現はあまり意味を成してない？
ので1ファイルにまとめたら名前空間で仕切られてるだけって考えでいいんじゃないか

**デフォルトの名無しさん** · 2016/09/03(土) 00:54:26.94

昔からある単なるmoduleはもうobsoleteですぐにnamespaceにリネームすべきだね
いわゆるモジュールはJavaScriptの世界を知らないと理解しがたいものになってるね

**デフォルトの名無しさん** · 2016/09/03(土) 00:56:21.93

ES6のmuduleが普及すればかなりシンプルになるんだろうけど、まだブラウザがサポートしてない

**デフォルトの名無しさん** · 2016/09/09(金) 21:36:47.25

letは再入不可にして欲しいなあ

**デフォルトの名無しさん** · 2016/09/09(金) 21:41:01.71

constじゃあかんの？

**デフォルトの名無しさん** · 2016/09/10(土) 07:30:02.50

なんか名前が先祖帰りっぽくてなあ

**デフォルトの名無しさん** · 2016/09/11(日) 01:15:44.93

>>436は「再入」不可と言ってんだが…

**デフォルトの名無しさん** · 2016/09/11(日) 01:38:43.42

リエントラントを意識したことが無かったりすると
再入って言葉を再代入の変わりに使ってもいいじゃん？とか思ってしまうのだろう

**デフォルトの名無しさん** · 2016/09/11(日) 08:21:20.09

「リエントラントな変数」はナンセンスだから、ま、多少はね？

**デフォルトの名無しさん** · 2016/09/14(水) 09:26:01.83

tsってjsに変換して型情報捨てちゃってるけどバイナリにコンパイルとかサポートしないのかな
WebAssemblyにそのまま使えたら面白いことになりそう

**デフォルトの名無しさん** · 2016/09/14(水) 09:52:25.62

asm.jsは文法だけjsのサブセットで実行モデルは全然違うんでサポートしないっつうかできなかったはずだが、WebAssemblyも同じじゃないの？

**デフォルトの名無しさん** · 2016/09/14(水) 10:28:43.01

折角の型情報を活かせるのが構文チェックだけで
高速化には寄与しないってのは勿体ないのは確かだな

**デフォルトの名無しさん** · 2016/09/14(水) 13:51:30.89

TypeScriptのビジョン的には、そういうのはESが新バージョンで型アノテーションを導入して
ブラウザによって最適化されるべきということなんじゃない?
ハックで実装するのはTypeScript的じゃないよ

**デフォルトの名無しさん** · 2016/09/14(水) 14:43:49.29

ES5と同じようにwasm用のサブセット作って段階的にサポートしていけば余裕しょ

**デフォルトの名無しさん** · 2016/09/14(水) 14:58:26.52

アセンブリレベルまでコンパイルしようと思えば現在JSに丸投げしてる部分をTSで独自に定義し直す必要があるから、
仕様はサブセットどころか無茶苦茶肥大化するよ

**デフォルトの名無しさん** · 2016/09/14(水) 15:06:48.85

どうせJavaやC#がWebAssemblyの出力に対応するだろうし、高速化を期待するならそっちを使うべきだな

**デフォルトの名無しさん** · 2016/09/14(水) 15:12:59.56

ただ、Webの世界はAPIが全てJavaScript用に定義されてる訳だから
DOMをいじるとかWeb関連のコードを書こうとしたらJavaScript使うのが一番楽だろう
で、TypeScriptを使えばエラーの少ないコードが書けるよってだけの存在だな

**デフォルトの名無しさん** · 2016/09/21(水) 09:53:22.62

netbeansでtsファイルをコンパイルできますか？

**デフォルトの名無しさん** · 2016/09/23(金) 07:28:38.08

TypeScript 2.0 正式リリース
https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/

**デフォルトの名無しさん** · 2016/09/25(日) 21:22:23.16

Visual Studio2015のTypeScript2.0で
if(1===2){
　...
}
とすると、
エラー TS2365 演算子 '===' を型 '1' および '2' に適用することはできません。
になるのですが、1と2を比較すると何が悪いのでしょうか？

**デフォルトの名無しさん** · 2016/09/25(日) 22:06:10.66

>>452
Tagged Union 由来のエラーのような気がする
ナンセンスなコードだけど、気になるようならエラーレポートしておいで
片方が変数なら問題ないから、普通にコードを書くうちは表面化しない

**デフォルトの名無しさん** · 2016/09/26(月) 03:17:54.07

>>451
Revised 型の国のTypeScript
http://typescript.ninja/typescript-in-definitelyland/

>>430
TypeScript 2.0.3 変更点
http://qiita.com/vvakame/items/826bf193dd301862014f

**デフォルトの名無しさん** · 2016/09/26(月) 12:48:28.20

型の国新人研修マニュアルみたいで微妙だった