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/03/23(水) 23:04:51.01

>>309
無理でしょう。TypeScriptのinterfaceはコンパイル後には何の痕跡も残らない。
実行時にはinterface由来の型情報は使えない。

**デフォルトの名無しさん** · 2016/03/24(木) 14:14:40.73

TypeScriptはコンパイル時にはinterfaceを認識してるはずだが
コードでそれをチェックする術がないな (今後も追加される事は絶対ないだろうが)

しかしinterfaceのどれかに合致するかっていう考え方ちょっと違うな
例えば
interface A {
　a:number
}
interface B {
　b:string
}
があれば
{
　a:1,
　b:"hoge"
}
はどっちにも合致する訳だから、コンパイルが通ればどれか(または両方)のinterfaceに合致してる
と判別が出来るってだけのものだよ

**デフォルトの名無しさん** · 2016/03/24(木) 17:51:19.94

chromeでデバッグできますか？

**デフォルトの名無しさん** · 2016/03/24(木) 18:45:20.46

>>312
.js にコンパイルするときに Source Map を出力できる。
それ以上のデバッグについては開発環境スレでどうぞ。

**デフォルトの名無しさん** · 2016/03/25(金) 02:00:24.75

>>312
weboack使ってるけどなんの問題もなくtsファイルにbreakpointが貼れる

**デフォルトの名無しさん** · 2016/03/25(金) 02:00:53.64

>>314
webpackです。typo

**デフォルトの名無しさん** · 2016/03/25(金) 12:36:24.15

>>314
iisサーバーは？

**デフォルトの名無しさん** · 2016/03/27(日) 23:00:49.72

typeScriptでWeakMapっていつから使えるようになるんですか？
ES2015から使えるものっててっきりtypeScriptでもつかえるものかと

**デフォルトの名無しさん** · 2016/03/28(月) 14:50:43.22

--target ES6にすれば使えるっていうかそれぐらい察しろ

**デフォルトの名無しさん** · 2016/03/28(月) 19:56:00.22

>>318
えっ。それっておかしくないです？
typeScriptって基本 ES2015 + 型なのかと。
アロー関数は標準でサポートしといてWeakMapは対象外ってどういうことなの

**デフォルトの名無しさん** · 2016/03/28(月) 21:20:10.15

>>319
構文糖で対応できる機能は対応している
JavaScriptエンジンが対応してくれないとどうしようもない機能は無理
それぐらい察しろ

**デフォルトの名無しさん** · 2016/03/29(火) 00:12:34.26

>>320
なるほど。てっきりtargetって出力するjsコードの対応バージョンでしかなくて、
typeScriptの仕様自体はどのtargetでも変化しないと思い込んでました。
つまりES2015のpolyfillの役割も果たしてくれるとばかり思っていました。
ありがとうございます。

**デフォルトの名無しさん** · 2016/03/29(火) 10:54:45.27

>>321
基本TypeScriptはES2015のpolifillだと思っていいけど
単に少ないコードで実装出来るものしか対応してないだけだ
__extendsとか__decorateとかね
2.0でasync/awaitもES5で使えるようになるけど、もしWeakMapを対応したら
巨大なコードが*.jsの頭に引っ付くことになるけどそんなの嫌だろ

**デフォルトの名無しさん** · 2016/04/05(火) 23:45:55.11

JavaのNashornにrequire関数組み込んでTypeScript使えるようにしたが結構楽しいわ
letの暗黙リネームが実行時に何か不具合起こすんじゃないかと少々気になる

**デフォルトの名無しさん** · 2016/04/06(水) 20:01:43.86

>>323
letが導入されてから1.8になるまでforループ内でlet使うと特定の条件で実行時エラーを起こしてた
1.8で修正されたから古いバージョンの場合は気を付けた方がいいけど1.8以降は不具合なんて起こさないはず

**デフォルトの名無しさん** · 2016/04/11(月) 23:59:54.54

typescript初心者です。
Visual Studioで、
module mod {
function func() {
alert('func');
}
}
が、
var mod;
(function (mod) {
function func() {
alert('func');
}
})(mod || (mod = {}));

になるのですが、分からないのは、
(mod || (mod = {}));
の部分です。
これは何でしょうか？
どなたか解説お願いいたします。あるいはヒントなどお教えください。

**デフォルトの名無しさん** · 2016/04/12(火) 00:19:14.57

>>325
mod 変数が定義済みなら再利用 or 無ければ新規の空オブジェクトを使う。
複数の場所で mod モジュールが定義される場合に、内容をマージすることになる。

**デフォルトの名無しさん** · 2016/04/12(火) 00:20:23.42

(A || B)はAもしくはBが偽じゃなければその内容(結果)を返す特性があって
単純に言うとmodが空ならオブジェクト代入して無名関数に渡すよってこと

**デフォルトの名無しさん** · 2016/04/12(火) 00:47:40.67

>>326 >>327
解説ありがとうございました。だいぶ分かってきました。
もう一つ教えて下さい。
二つのtsファイル
----------------
// file1.ts
module mod {
　　function func1() {
　　　　alert('func1');
　　}
}
----------------
// file2.ts
module mod {
　　function func2() {
　　　　alert('func2');
　　}
}
----------------

**デフォルトの名無しさん** · 2016/04/12(火) 00:48:40.40

から生成される二つのjsファイルを単純に連結して一つのファイルにします。
----------------
var mod;
(function (mod) {
　　function func1() {
　　　　alert('func1');
　　}
})(mod || (mod = {}));

var mod;
(function (mod) {
　　function func2() {
　　　　alert('func2');
　　}
})(mod || (mod = {}));
----------------
こういう単純な例だと問題は無かったのですが、実際の状況では連結したJSの実行時にエラーする場合がありました。
少し調べた限りでは、エラーの有無はJSファイルを連結する順番に依存するようなのですが、そういう事はありますか？
やりたいのは、複数のJSファイルをmoduleで囲ってTS化して、そうやって出来上がったJSファイルを一つのファイルに連結したいのですが、エラーが出て行き詰っています。
こういうやり方は間違いですか？

**デフォルトの名無しさん** · 2016/04/12(火) 10:30:36.29

>>329
連結する順番でエラーになることはある。
特にグローバルスコープ（関数の外）で処理が走る場合かな？

tslint を入れて no-use-before-declare (宣言前に使うと警告) で
チェックする手はあるかもしれない。

**デフォルトの名無しさん** · 2016/04/12(火) 12:30:46.37

>>330
情報ありがとうございました。
調べてみます。

**デフォルトの名無しさん** · 2016/04/12(火) 21:56:30.51

TypeScript 2.0プレビュー
http://www.infoq.com/jp/news/2016/04/typescript-2-preview

**デフォルトの名無しさん** · 2016/04/13(水) 16:45:42.60

おおって思ってchannel9の動画見てみたらマイクロソフトの人が未だにtsd
使ってデモしてたんだけどtsd非推奨じゃなかったんかい

**デフォルトの名無しさん** · 2016/04/13(水) 16:56:49.53

面白いねTypeScript2.0

undefinedとnullはそれぞれ独立した型になって
let a: number|null|undefined
みたいに宣言するようになるのか

**デフォルトの名無しさん** · 2016/04/13(水) 22:27:08.77

voidでよくね

**デフォルトの名無しさん** · 2016/04/14(木) 12:17:58.56

C#のvirtual,overrideも実装してくれよ
issueには何度かあがってるけどその度に否定されてんだよな、何でだ

**デフォルトの名無しさん** · 2016/05/01(日) 13:04:39.03

匿名通信（Tor、i2p等）ができるファイル共有ソフトBitComet（ビットコメット）みたいな、
BitTorrentがオープンソースで開発されています

言語は何でも大丈夫だそうなので、P2P書きたい！って人居ませんか？

Covenantの作者（Lyrise）がそういう人と話したいそうなので、よろしければツイートお願いします
https://twitter.com/Lyrise_al

ちなみにオイラはCovenantの完成が待ち遠しいプログラミングできないアスペルガーｗ

The Covenant Project
概要

Covenantは、純粋P2Pのファイル共有ソフトです

目的

インターネットにおける権力による抑圧を排除することが最終的な目標です。そのためにCovenantでは、中央に依存しない、高効率で検索能力の高いファイル共有の機能をユーザーに提供します

特徴

Covenant = Bittorrent + Abstract Network + DHT + (Search = WoT + PoW)

接続は抽象化されているので、I2P, Tor, TCP, Proxy, その他を利用可能です
DHTにはKademlia + コネクションプールを使用します
UPnPによってポートを解放することができますが、Port0でも利用可能です(接続数は少なくなります)
検索リクエスト、アップロード、ダウンロードなどのすべての通信はDHT的に分散され、特定のサーバーに依存しません
４

**デフォルトの名無しさん** · 2016/05/01(日) 20:44:35.23

Visual Studio Comm. 2015でTypeScript 1.7.4.0を使ってます。
プロジェクトをビルドしてデバッグしても変更が反映されなくなりました。
仕方なく新しいプロジェクトを作ってソースを移動させているのですが、対処法はありますか？

**デフォルトの名無しさん** · 2016/05/01(日) 21:13:58.28

>>338
＞変更が反映されなくなりました。
何の変更がどこに反映されないん？
tsからjsが自動生成されないと言う意味？
もしそうならtsに文法エラーが有るんじゃないか？

**デフォルトの名無しさん** · 2016/05/02(月) 10:47:24.02

レスありがとうございます。こんなに早く反応があるとは思いませんでした。見逃してしまって申し訳ないです。

＞何の変更がどこに反映されないのか
ソースコードの変更です。
ビルドして実行してもjsが前回のビルドのままで困っていました。

＞tsからjsが自動生成されないと言う意味？
＞もしそうならtsに文法エラーが有るんじゃないか？
仰る通り文法エラーがあったみたいです。今では正常に実行できています。ご迷惑をおかけしました。

それにしても間違ったコードを書いてもビルドエラーにはならないんですね……。
これではどこでミスったかチェックしにくい。

**デフォルトの名無しさん** · 2016/05/02(月) 16:08:44.94

「新しいプロジェクトを作ってソースを移動させ」たらうまくいくのだがという話じゃなかったのか

**デフォルトの名無しさん** · 2016/05/03(火) 07:37:48.31

「新しいプロジェクトを作ってソースを移動させたらうまくいく」ケースは俺も何度か経験したことがあるなぁ
しかも>>338と違ってコンパイルエラーは発生していない

ビルドして実行してもjsが前回のビルドのままってところまでは一致してるんだよな
（そもそもビルドできないのだが）

**デフォルトの名無しさん** · 2016/05/09(月) 17:02:14.42

Visual Studio2015で二つのTSのプロジェクトがあり、
Proj1
　typescrpt1.ts
　commonA.ts
　commonB.ts

Proj2
　typescrpt2.ts
　commonA.ts
　commonB.ts

両者で共通のtsファイルが二つあるのだが、こう言う場合、オリジナルをProj1に入れておいて、
Proj2から参照するようなやり方は出来る？
現状では、Proj1でCommonA,Bを変更する度にPorj2に手作業でコピーしているのだが、
それだと毎回そんな作業するのが手間だし、うっかりProj2側でCommonのファイルを変更すると
逆にProj1にも修正をしなくてはならないので困るのだが。

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

既存のファイルを追加すれば参照してくれるでしょ
プロジェクト以下に収めなきゃいけない理由がないなら
common, proj1, proj2と横並びにすればいい

**デフォルトの名無しさん** · 2016/05/09(月) 17:28:41.05

>>344
レスありがとうございました。
既存のファイルを追加すると、そのコピーが追加されるので、結局343 で
説明したようなファイル構造になります。
困っています。

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

だれも分からないの？

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

VSでTypeScriptやってる人が少ないんでないの？
CとかC++を一緒にやってる人じゃないと最近の人はVSCodeを使うだろうし

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

>>347
VSCodeだと343のような状況はどうなるの？
共通部分は一元管理が出来るの？

**デフォルトの名無しさん** · 2016/05/10(火) 22:20:05.90

私もやり方知りたいが分からんのでスタティックリンクにしてるがそれじゃ駄目？

**デフォルトの名無しさん** · 2016/05/10(火) 22:23:56.70

>>349
windowsでスタテクリンク出来る？

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

ジャンクションでググて

**デフォルトの名無しさん** · 2016/05/10(火) 22:34:19.65

>>343
思想的には commonA/B を独立したプロジェクトにしてモジュールとして再利用するんだろうな。
こっそり同一ファイル扱いにするならファイル or フォルダをシンボリックリンクにするか。
これと似たようなものだが、昔は svn:externals を使ったこともあったな。

**デフォルトの名無しさん** · 2016/05/11(水) 21:11:57.56

WindowsXPはハードリンクが出来るようになって便利だからフォルダをハードリンクにしたんだ
で、リンクした方が不要になったからごみ箱に入れたんだ
まだ、元のフォルダ内はなんともなかった
暫くたってごみ箱を空にしたんだよ
そしたら元のフォルダ内のファイルが全部消去されちまったんだよ！当然ごみ箱にも無い
要するにWindowsでフォルダをハードリンクすんなって事

**デフォルトの名無しさん** · 2016/05/11(水) 22:31:42.85

ジャンクションでも似たような問題あるのか、、
http://d.hatena.ne.jp/foldrr/touch/20091120/p1
いまはどうなんだろう

**デフォルトの名無しさん** · 2016/05/12(木) 18:40:46.37

>>353
Windowsってフォルダのハードリンク作れたっけ？

**デフォルトの名無しさん** · 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メソッドのほうがまだ芽がある気がするが