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/
TypeScript part2 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
1デフォルトの名無しさん
2015/04/30(木) 18:37:29.98ID:ynMflk1l388デフォルトの名無しさん
2016/07/26(火) 15:46:52.18ID:iOw6CH/m プロトタイプベースは人類には早すぎたんだ
クラスベースでないと万人には理解できない
クラスベースでないと万人には理解できない
389デフォルトの名無しさん
2016/07/26(火) 16:29:48.15ID:GAZIoYVE プロトタイプベースは既存のインスタンスから継承できる先進的な機能ではあるが
そもそも他の言語では隠されてる継承の仕組みがむき出しになってるだけなんで
無理に使う必要もない
クラスを作るイディオムとか普通にclassを使えばいいんだ
そもそも他の言語では隠されてる継承の仕組みがむき出しになってるだけなんで
無理に使う必要もない
クラスを作るイディオムとか普通にclassを使えばいいんだ
390デフォルトの名無しさん
2016/07/27(水) 06:57:54.53ID:Pn9H7j+u >>387
歴史は繰り返す
歴史は繰り返す
391デフォルトの名無しさん
2016/07/27(水) 13:58:29.20ID:lrmpmMbD WebAssemblyは当面C++のゲーム用だけどDOMもいじれるようになる予定だから
そうなるとまたWeb用言語の勢力図は変わるかもしれないな
Webの世界に安定は無い
そうなるとまたWeb用言語の勢力図は変わるかもしれないな
Webの世界に安定は無い
392デフォルトの名無しさん
2016/07/27(水) 14:22:46.06ID:5Q3W/uen デバッガが当分クソそうだけどWebKitはそのうち充実させて生JS殺しにきそう
393デフォルトの名無しさん
2016/07/27(水) 23:47:21.54ID:Bmh+9kmU394デフォルトの名無しさん
2016/07/28(木) 06:25:04.12ID:jPXeBRxR FunScriptでもやるか
395デフォルトの名無しさん
2016/07/28(木) 19:15:17.96ID:O8Vfrh0P >>393
LLVMじゃね
LLVMじゃね
396デフォルトの名無しさん
2016/07/29(金) 10:57:47.10ID:eqy9GKk1 2.0のstrictNullChecksへの対応は結構キツイなぁ
「フィールドAがあれば、フィールドBも必ずある」ような暗黙ルールを咎められる
「変数?」が「型 | undefined」の扱いになるから
無効な値にはnullを使わずundefinedで統一したほうが良さそうだ
構文としては、返値、ローカル変数、末尾以外の引数にundefinedを許したい場合
いちいち「| undefined」が必要になる。Swiftのように ? は型の側が良い気がするんだが
「フィールドAがあれば、フィールドBも必ずある」ような暗黙ルールを咎められる
「変数?」が「型 | undefined」の扱いになるから
無効な値にはnullを使わずundefinedで統一したほうが良さそうだ
構文としては、返値、ローカル変数、末尾以外の引数にundefinedを許したい場合
いちいち「| undefined」が必要になる。Swiftのように ? は型の側が良い気がするんだが
397デフォルトの名無しさん
2016/07/29(金) 14:56:44.05ID:LtIoC4Yb undefinedはプロパティそのものが存在しないことを表すんだからプロパティ側に?付けるのは自然でしょ
2.0は個人的にはかなり好きだな
最近の新言語といえばWeb系のノリで適当に作られてるのが多い中、これほど思想が明確で一貫した言語は珍しい
2.0は個人的にはかなり好きだな
最近の新言語といえばWeb系のノリで適当に作られてるのが多い中、これほど思想が明確で一貫した言語は珍しい
398デフォルトの名無しさん
2016/07/29(金) 16:06:58.19ID:eqy9GKk1 「存在しない」と「undefinedを保持している」の2つの意味があるからなぁ
前者ならプロパティの属性、後者なら型の属性に解釈できるように感じる
strictNullChecksは簡単には対応できなかったが
noImplicitThis, noUnusedLocals, noUnusedParameters は
影響が少ないわりにバグを拾ってくれてありがたかった
前者ならプロパティの属性、後者なら型の属性に解釈できるように感じる
strictNullChecksは簡単には対応できなかったが
noImplicitThis, noUnusedLocals, noUnusedParameters は
影響が少ないわりにバグを拾ってくれてありがたかった
399デフォルトの名無しさん
2016/07/29(金) 23:41:16.66ID:rRyJkXWQ >>398
JavaScriptはundefineって言われても本当にundefinedなのか意図的に設定したundefinedか判別不能だから
nullとundefinedを区別する意味があるけど、TypeScriptの場合は「存在しない」なんて有り得ないからnullは要らない子だし
undefinedの場合は意図的に設定したと分かる
JavaScriptはundefineって言われても本当にundefinedなのか意図的に設定したundefinedか判別不能だから
nullとundefinedを区別する意味があるけど、TypeScriptの場合は「存在しない」なんて有り得ないからnullは要らない子だし
undefinedの場合は意図的に設定したと分かる
400デフォルトの名無しさん
2016/07/30(土) 00:18:48.03ID:tmproLvF ノードの有無のチェックは存在を確認するし番兵は一般的にnullを使う
前者はプロパティで後者は型だろう
前者はプロパティで後者は型だろう
401デフォルトの名無しさん
2016/07/30(土) 08:46:23.50ID:d/v3ZRhl F#「あなたはヌルチェックでどれほど人生を無駄使いしているかを知るべきである」
402デフォルトの名無しさん
2016/07/30(土) 13:20:14.13ID:NnN7Vre0 ===を使えば全部解決
403デフォルトの名無しさん
2016/07/30(土) 23:28:44.49ID:r21OKS05 "型?" については "| null"、"| undefined"、その両方の
どれにすべきかで議論がまとまらなかったみたいだ
しばらくは採用されないだろう
https://github.com/Microsoft/TypeScript/issues/7426
https://github.com/Microsoft/TypeScript/issues/7488
どれにすべきかで議論がまとまらなかったみたいだ
しばらくは採用されないだろう
https://github.com/Microsoft/TypeScript/issues/7426
https://github.com/Microsoft/TypeScript/issues/7488
404デフォルトの名無しさん
2016/08/01(月) 14:04:09.45ID:FziUxCeM >>400
DOMとかWebGLとか普通にnullを返すからどうしてもnullを使わないといけない場面は出てくる
けど、TypeScriptだけの処理の場合はnullを使う意味は全く無いな
本家のコーディングスタイルにもnullじゃなくundefinedを使えと書いてある
DOMとかWebGLとか普通にnullを返すからどうしてもnullを使わないといけない場面は出てくる
けど、TypeScriptだけの処理の場合はnullを使う意味は全く無いな
本家のコーディングスタイルにもnullじゃなくundefinedを使えと書いてある
405デフォルトの名無しさん
2016/08/01(月) 18:46:01.78ID:2iI0/+FF JavaScriptの根幹にある設計ミスだからな
トランスパイラの層ではその尻を拭うのも難しかろう
トランスパイラの層ではその尻を拭うのも難しかろう
406デフォルトの名無しさん
2016/08/01(月) 19:32:59.87ID:RWxbqWQ0 >>404
知ってるけど命令型アルゴリズムを書くときにわざわざnullをundefinedに置換するほどのメリットもない
教科書通りnull使ったほうが思考のオーバーヘッドがなくて楽
どちらでもいい時はundefinedに寄せる
知ってるけど命令型アルゴリズムを書くときにわざわざnullをundefinedに置換するほどのメリットもない
教科書通りnull使ったほうが思考のオーバーヘッドがなくて楽
どちらでもいい時はundefinedに寄せる
407デフォルトの名無しさん
2016/08/01(月) 22:13:22.57ID:cFMFBdlm Suggestion: Extension methods
https://github.com/Microsoft/TypeScript/issues/9
初期から提案のあった拡張メソッドだが、不採用が決まった
https://github.com/Microsoft/TypeScript/issues/9
初期から提案のあった拡張メソッドだが、不採用が決まった
408デフォルトの名無しさん
2016/08/02(火) 00:27:46.69ID:EfYzXtbg 型の有無で動作が変わるのはTypeScriptの設計思想からして不適切
409デフォルトの名無しさん
2016/08/02(火) 12:10:13.85ID:rXn2IC8I クラス定義には含まれないプロパティをインスタンスが持てる言語で
そもそも拡張メソッドが成り立つものなのかね?
Java interfaceのdefaultメソッドのほうがまだ芽がある気がするが
そもそも拡張メソッドが成り立つものなのかね?
Java interfaceのdefaultメソッドのほうがまだ芽がある気がするが
410デフォルトの名無しさん
2016/08/02(火) 17:21:45.08ID:04yi8jv3411デフォルトの名無しさん
2016/08/02(火) 18:37:46.13ID:+e4iDA+F >>410
アルゴリズムの本じゃね?
アルゴリズムの本じゃね?
412デフォルトの名無しさん
2016/08/03(水) 00:12:57.56ID:jr+ageRA nullかどうか判定するのに
hoge === null
とかやってないよな?
!hoge
で統一すればundefinedのみで何の問題も無い
hoge === null
とかやってないよな?
!hoge
で統一すればundefinedのみで何の問題も無い
413デフォルトの名無しさん
2016/08/03(水) 01:16:56.62ID:Ot1v5VqO これはひどい釣り
414デフォルトの名無しさん
2016/08/03(水) 08:01:27.31ID:8fjgpLNn 数値と文字が渡されないケースなら ! でも良い
渡されるなら == null (2個) を使う
TSLintの設定で、比較で null を使うのは許して、値としては許さないのが欲しいな
渡されるなら == null (2個) を使う
TSLintの設定で、比較で null を使うのは許して、値としては許さないのが欲しいな
415デフォルトの名無しさん
2016/08/03(水) 12:08:49.21ID:mbys/AN5 null汚染
416デフォルトの名無しさん
2016/08/03(水) 14:40:42.74ID:3251V7HB >>413
お前がど素人なのはわかったよw
お前がど素人なのはわかったよw
417デフォルトの名無しさん
2016/08/03(水) 17:20:15.41ID:3251V7HB >>413,414とかってnumberな変数にnullとか代入しちゃってんだろうな…
そりゃstrictNullChecksで困るわけだ
そりゃstrictNullChecksで困るわけだ
418デフォルトの名無しさん
2016/08/03(水) 21:04:30.24ID:Ot1v5VqO 入れるわけねーだろバカ
419デフォルトの名無しさん
2016/08/03(水) 22:55:31.78ID:Ve2x0gaK 皆さん結局nullとundefinedを区別しているの?どんなコードを書いているの?
420デフォルトの名無しさん
2016/08/03(水) 23:55:39.77ID:8fjgpLNn 一つの変数で区別する用途を無理やり考えるならば
・undefined: 初期化前
・null: 利用不可
・object: 利用可
なんて例があるかもしれない。普通はNullObjectで済ませるか
・undefined: 初期化前
・null: 利用不可
・object: 利用可
なんて例があるかもしれない。普通はNullObjectで済ませるか
421デフォルトの名無しさん
2016/08/04(木) 02:41:29.69ID:0QnTEdcF422デフォルトの名無しさん
2016/08/04(木) 09:59:24.73ID:aMt1KCpE strictNullChecksを気持ちよく使いたいなら構造から見直しになるな
{ x?, y? } // 必ずペアで使う
ではなく
{ pt?: { x, y } }
としないと ! を避けられない
{ x?, y? } // 必ずペアで使う
ではなく
{ pt?: { x, y } }
としないと ! を避けられない
423デフォルトの名無しさん
2016/08/08(月) 22:15:39.27ID:W4Hzna5O だれかtypeScriptでバリバリサーバサイドもやってるぜって人いる?
使い勝手を是非聞きたい
使い勝手を是非聞きたい
424デフォルトの名無しさん
2016/08/25(木) 22:38:44.02ID:yGHELMdE マクロのミスでconst enum同士で除算しちゃってて間違い探しをする羽目になったぜ
ありえない数値になってたのにコンパイラは叱ってくれなかったよ
ありえない数値になってたのにコンパイラは叱ってくれなかったよ
425デフォルトの名無しさん
2016/08/26(金) 07:44:50.99ID:LCNVy+4G >>424
enum同士の除算結果の型はnumberだから、コンパイラの解釈は妥当だぞ
「単位付き数値」があればエラーにできるケースもあるかもしれない
Nominal typesの一環で良い感じの機能が入らないものか
enum同士の除算結果の型はnumberだから、コンパイラの解釈は妥当だぞ
「単位付き数値」があればエラーにできるケースもあるかもしれない
Nominal typesの一環で良い感じの機能が入らないものか
426デフォルトの名無しさん
2016/08/26(金) 10:18:15.73ID:uxIG+t+y numberからconst enumへ暗黙的な変換が許されるのが問題だと思ったんよ
警告されれば先に気づくことができたから
警告されれば先に気づくことができたから
427デフォルトの名無しさん
2016/08/26(金) 15:52:13.72ID:mbeLOtT9 暗黙も何もenumの要素は最初からただのnumberだからな
JavaScriptとの互換性を考えれば妥当な仕様だろう
JavaScriptとの互換性を考えれば妥当な仕様だろう
428デフォルトの名無しさん
2016/08/26(金) 16:16:08.43ID:LCNVy+4G 他言語と比べると確かにチェックがガバガバだが
interfaceを明示的にimplementsしなくてもシグニチャだけを見ることと比べると
一貫性はあるとは思う。型システムがStructuralなことの弊害だろう
数値でなくても良いなら enum より String Literal Types を使うべきなんだろうな
interfaceを明示的にimplementsしなくてもシグニチャだけを見ることと比べると
一貫性はあるとは思う。型システムがStructuralなことの弊害だろう
数値でなくても良いなら enum より String Literal Types を使うべきなんだろうな
429デフォルトの名無しさん
2016/08/26(金) 16:48:05.33ID:mbeLOtT9 型システム自体はJavaScript側にあるんだ
TypeScriptがやってる事はJavaScriptのソースに書かれてる型を見えるようにしてるだけとも言える
そもそもJavaScriptが動的型なんだから無理やり静的型にしようとしても微妙なところは出てくるだろうな
TypeScriptがやってる事はJavaScriptのソースに書かれてる型を見えるようにしてるだけとも言える
そもそもJavaScriptが動的型なんだから無理やり静的型にしようとしても微妙なところは出てくるだろうな
430デフォルトの名無しさん
2016/09/01(木) 04:24:05.73ID:oFB7MvRf 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
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
431デフォルトの名無しさん
2016/09/02(金) 02:34:58.82ID:D4RF+Hn1 switch使うとダサくなるな
match withにして欲しい
match withにして欲しい
432デフォルトの名無しさん
2016/09/02(金) 15:48:27.54ID:LgVEFfHs 内部モジュールについて教えてください。
これを使う場合ってconcatで1ファイル化する場合ってことでいいんでしょうか
webpackをつかって1ファイル化する予定なんですがその場合は外部モジュールを使う認識であっていますか?
これを使う場合ってconcatで1ファイル化する場合ってことでいいんでしょうか
webpackをつかって1ファイル化する予定なんですがその場合は外部モジュールを使う認識であっていますか?
433デフォルトの名無しさん
2016/09/02(金) 17:23:11.44ID:dDo1g1S1 外部モジュールになるファイルは独立してるはず
今はnamespace推奨で内部モジュールって表現はあまり意味を成してない?
ので1ファイルにまとめたら名前空間で仕切られてるだけって考えでいいんじゃないか
今はnamespace推奨で内部モジュールって表現はあまり意味を成してない?
ので1ファイルにまとめたら名前空間で仕切られてるだけって考えでいいんじゃないか
434デフォルトの名無しさん
2016/09/03(土) 00:54:26.94ID:FrYijLTu 昔からある単なるmoduleはもうobsoleteですぐにnamespaceにリネームすべきだね
いわゆるモジュールはJavaScriptの世界を知らないと理解しがたいものになってるね
いわゆるモジュールはJavaScriptの世界を知らないと理解しがたいものになってるね
435デフォルトの名無しさん
2016/09/03(土) 00:56:21.93ID:FrYijLTu ES6のmuduleが普及すればかなりシンプルになるんだろうけど、まだブラウザがサポートしてない
436デフォルトの名無しさん
2016/09/09(金) 21:36:47.25ID:oMlYA35z letは再入不可にして欲しいなあ
437デフォルトの名無しさん
2016/09/09(金) 21:41:01.71ID:0o6Zl0oX constじゃあかんの?
438デフォルトの名無しさん
2016/09/10(土) 07:30:02.50ID:XD8JXdoT なんか名前が先祖帰りっぽくてなあ
439デフォルトの名無しさん
2016/09/11(日) 01:15:44.93ID:PWIs+lC0 >>436は「再入」不可と言ってんだが…
440デフォルトの名無しさん
2016/09/11(日) 01:38:43.42ID:m+TGnnw0 リエントラントを意識したことが無かったりすると
再入って言葉を再代入の変わりに使ってもいいじゃん?とか思ってしまうのだろう
再入って言葉を再代入の変わりに使ってもいいじゃん?とか思ってしまうのだろう
441デフォルトの名無しさん
2016/09/11(日) 08:21:20.09ID:o8qO+nVm 「リエントラントな変数」はナンセンスだから、ま、多少はね?
442デフォルトの名無しさん
2016/09/14(水) 09:26:01.83ID:tSXXNMuv tsってjsに変換して型情報捨てちゃってるけどバイナリにコンパイルとかサポートしないのかな
WebAssemblyにそのまま使えたら面白いことになりそう
WebAssemblyにそのまま使えたら面白いことになりそう
443デフォルトの名無しさん
2016/09/14(水) 09:52:25.62ID:EEwsGEAZ asm.jsは文法だけjsのサブセットで実行モデルは全然違うんでサポートしないっつうかできなかったはずだが、WebAssemblyも同じじゃないの?
444デフォルトの名無しさん
2016/09/14(水) 10:28:43.01ID:8JRyg+5x 折角の型情報を活かせるのが構文チェックだけで
高速化には寄与しないってのは勿体ないのは確かだな
高速化には寄与しないってのは勿体ないのは確かだな
445デフォルトの名無しさん
2016/09/14(水) 13:51:30.89ID:Adg+xGfe TypeScriptのビジョン的には、そういうのはESが新バージョンで型アノテーションを導入して
ブラウザによって最適化されるべきということなんじゃない?
ハックで実装するのはTypeScript的じゃないよ
ブラウザによって最適化されるべきということなんじゃない?
ハックで実装するのはTypeScript的じゃないよ
446デフォルトの名無しさん
2016/09/14(水) 14:43:49.29ID:UUl7aTux ES5と同じようにwasm用のサブセット作って段階的にサポートしていけば余裕しょ
447デフォルトの名無しさん
2016/09/14(水) 14:58:26.52ID:Adg+xGfe アセンブリレベルまでコンパイルしようと思えば現在JSに丸投げしてる部分をTSで独自に定義し直す必要があるから、
仕様はサブセットどころか無茶苦茶肥大化するよ
仕様はサブセットどころか無茶苦茶肥大化するよ
448デフォルトの名無しさん
2016/09/14(水) 15:06:48.85ID:eWqPmXTS どうせJavaやC#がWebAssemblyの出力に対応するだろうし、高速化を期待するならそっちを使うべきだな
449デフォルトの名無しさん
2016/09/14(水) 15:12:59.56ID:eWqPmXTS ただ、Webの世界はAPIが全てJavaScript用に定義されてる訳だから
DOMをいじるとかWeb関連のコードを書こうとしたらJavaScript使うのが一番楽だろう
で、TypeScriptを使えばエラーの少ないコードが書けるよってだけの存在だな
DOMをいじるとかWeb関連のコードを書こうとしたらJavaScript使うのが一番楽だろう
で、TypeScriptを使えばエラーの少ないコードが書けるよってだけの存在だな
450デフォルトの名無しさん
2016/09/21(水) 09:53:22.62ID:ye3OhaXn netbeansでtsファイルをコンパイルできますか?
451デフォルトの名無しさん
2016/09/23(金) 07:28:38.08ID:wUPl9fHa TypeScript 2.0 正式リリース
https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/
https://blogs.msdn.microsoft.com/typescript/2016/09/22/announcing-typescript-2-0/
452デフォルトの名無しさん
2016/09/25(日) 21:22:23.16ID:rgw8PMte Visual Studio2015のTypeScript2.0で
if(1===2){
...
}
とすると、
エラー TS2365 演算子 '===' を型 '1' および '2' に適用することはできません。
になるのですが、1と2を比較すると何が悪いのでしょうか?
if(1===2){
...
}
とすると、
エラー TS2365 演算子 '===' を型 '1' および '2' に適用することはできません。
になるのですが、1と2を比較すると何が悪いのでしょうか?
453デフォルトの名無しさん
2016/09/25(日) 22:06:10.66ID:s0l/HB/m >>452
Tagged Union 由来のエラーのような気がする
ナンセンスなコードだけど、気になるようならエラーレポートしておいで
片方が変数なら問題ないから、普通にコードを書くうちは表面化しない
Tagged Union 由来のエラーのような気がする
ナンセンスなコードだけど、気になるようならエラーレポートしておいで
片方が変数なら問題ないから、普通にコードを書くうちは表面化しない
454デフォルトの名無しさん
2016/09/26(月) 03:17:54.07ID:Pt8k1v+W >>451
Revised 型の国のTypeScript
http://typescript.ninja/typescript-in-definitelyland/
>>430
TypeScript 2.0.3 変更点
http://qiita.com/vvakame/items/826bf193dd301862014f
Revised 型の国のTypeScript
http://typescript.ninja/typescript-in-definitelyland/
>>430
TypeScript 2.0.3 変更点
http://qiita.com/vvakame/items/826bf193dd301862014f
455デフォルトの名無しさん
2016/09/26(月) 12:48:28.20ID:KtFZyGzz 型の国新人研修マニュアルみたいで微妙だった
456デフォルトの名無しさん
2016/09/26(月) 14:39:12.43ID:ymOrEJcI 一瞬変な絵が出てブラクラかと思った
http://techbooster.github.io/c90/#typescript
http://techbooster.github.io/c90/#typescript
457デフォルトの名無しさん
2016/09/26(月) 23:44:06.70ID:9aeHOXYg >>452
これは興味深い挙動だな
確かにnumberよりも1や2という「型」の方がより特殊化されてるからそっちで比較されちゃったんだろうな
let n: 1 = 1;
if (n === 2) { // 同じエラー
if (n === <number>2) { // OK (もちろんfalseになる)
number型定数のデフォがnumber型だと最初がエラーにならなくなるから難しい問題だな
定数同士の比較の時は型を昇格させるみたいな処理を追加する事になるのかな
これは興味深い挙動だな
確かにnumberよりも1や2という「型」の方がより特殊化されてるからそっちで比較されちゃったんだろうな
let n: 1 = 1;
if (n === 2) { // 同じエラー
if (n === <number>2) { // OK (もちろんfalseになる)
number型定数のデフォがnumber型だと最初がエラーにならなくなるから難しい問題だな
定数同士の比較の時は型を昇格させるみたいな処理を追加する事になるのかな
458デフォルトの名無しさん
2016/09/27(火) 00:14:39.14ID:pG4L5ums literal types増えたのリリースノートに書いてあるだろ
アナウンスのドキュメントさえ読まないバカが賢ぶってもまるわかりなんだよ
アナウンスのドキュメントさえ読まないバカが賢ぶってもまるわかりなんだよ
459デフォルトの名無しさん
2016/09/27(火) 00:21:02.93ID:DHOAQjGg 変なのが来た
460デフォルトの名無しさん
2016/09/27(火) 13:49:47.90ID:cO8I5ivP Delphiか、、Prismはお試しで終わったっけな
461デフォルトの名無しさん
2016/09/27(火) 16:37:55.22ID:LSfhFpLX espower-typescriptのtypescript2対応版ってないですか?
462デフォルトの名無しさん
2016/09/27(火) 18:40:40.20ID:LSfhFpLX espower-typescriptは自動でproject rootのtsconfig.jsonを参照しているんですが
別ファイルで指定する方法ないでしょうか?
別ファイルで指定する方法ないでしょうか?
463デフォルトの名無しさん
2016/09/27(火) 22:52:10.27ID:K3k5rGhG464デフォルトの名無しさん
2016/09/30(金) 12:56:49.51ID:Y6l190wq typescriptでは、
こういう書き方をするようですが、
$(document).ready(() => { ... });
普通の書き方
$(document).ready(function () { ... });
だとダメなのでしょうか?
こういう書き方をするようですが、
$(document).ready(() => { ... });
普通の書き方
$(document).ready(function () { ... });
だとダメなのでしょうか?
465デフォルトの名無しさん
2016/09/30(金) 13:07:29.24ID:LMNz6D7V >>464
全く問題ないよ。関数内のthisの指し先の違いにだけ注意がいる
全く問題ないよ。関数内のthisの指し先の違いにだけ注意がいる
466デフォルトの名無しさん
2016/09/30(金) 17:16:18.31ID:ff48EwFg >>464
typeScriptというよりes2015ですね。
typeScriptというよりes2015ですね。
467デフォルトの名無しさん
2016/10/05(水) 16:03:45.86ID:ndferu82 jQueryの場合はコールバック内で$(this)とかするけど() => {にするとおかしな事になる(最新だとどうなるかは分からん)
だからjQueryに渡す場合は全部functionにしてる。一貫性がなくなって気持ち悪いけど
だからjQueryに渡す場合は全部functionにしてる。一貫性がなくなって気持ち悪いけど
468デフォルトの名無しさん
2016/10/06(木) 09:02:48.12ID:RX03s8Mg どちらも関数ではあるけど用途に違いがある以上、元より一貫性を出すことなんてできないでしょ
469デフォルトの名無しさん
2016/10/06(木) 15:59:28.90ID:xaiWfMZS () => {}.bind(this)
470デフォルトの名無しさん
2016/10/06(木) 20:20:49.67ID:57+jsWi1471デフォルトの名無しさん
2016/10/07(金) 14:51:03.71ID:CXORFQa6 null合体演算子はありますか?
472デフォルトの名無しさん
2016/10/08(土) 21:45:49.55ID:2uwi8nYQ >>471
|| のことかな? falseだとダメだけど
|| のことかな? falseだとダメだけど
473デフォルトの名無しさん
2016/10/20(木) 18:22:59.19ID:UBHF5fAS typescriptでnode_modules配下のjsコードのimportは可能ですが
自作のjsコードをimportして使いたいのですが可能でしょうか?
具体的に言うとpegjsで作ったparserをtypescriptから使いたいんです。
自作のjsコードをimportして使いたいのですが可能でしょうか?
具体的に言うとpegjsで作ったparserをtypescriptから使いたいんです。
474デフォルトの名無しさん
2016/10/21(金) 09:58:59.53ID:xTFSBjWO475デフォルトの名無しさん
2016/10/21(金) 10:02:09.42ID:PxEW311p 公開部分だけなら自分で定義ファイル書くのは容易なんじゃないか
もしくはソースをTypeScriptに変換しちゃって-d付きでコンパイル
もしくはソースをTypeScriptに変換しちゃって-d付きでコンパイル
476デフォルトの名無しさん
2016/10/21(金) 12:40:55.64ID:xTFSBjWO ちょっと考えればtsだってjsに変換してからimportしてるわけだからエラーが出てるようにみえるのは
定義がないだけってわかるだろうに。アホですな。
定義がないだけってわかるだろうに。アホですな。
477デフォルトの名無しさん
2016/10/24(月) 23:34:32.07ID:oa9Cbf2z typescript2.0から.d.tsのデフォルトの検索パスってどうなってるんですかね?
とりあえず自分で定義したのはnode_modules/@types/ に置くことで認識はするんですけど
気持ち悪いのでできればnode_modulesに置きたくないんですよね
とりあえず自分で定義したのはnode_modules/@types/ に置くことで認識はするんですけど
気持ち悪いのでできればnode_modulesに置きたくないんですよね
478デフォルトの名無しさん
2016/10/25(火) 00:14:10.49ID:jY50IjHL その手の質問はQ&Aサービス使え
479デフォルトの名無しさん
2016/10/25(火) 09:54:10.21ID:wi8xj/Ad480デフォルトの名無しさん
2016/10/25(火) 15:38:46.44ID:DJibeu24 そう言わずに教えてあげればいいじゃない。どうせ話題もないんだし
481デフォルトの名無しさん
2016/10/25(火) 16:45:27.88ID:k0D4gpoS .net frameworkを使えたりframeworkからコンパイルできれば面白くなりそうなのに
482デフォルトの名無しさん
2016/10/25(火) 18:39:55.45ID:UTXk7OSn たしかに .Net Framework使えたら便利だな
現状ではNode.jsから外部コマンドを叩いて
C#やPowerShellを経由すればできるんじゃね
現状ではNode.jsから外部コマンドを叩いて
C#やPowerShellを経由すればできるんじゃね
483デフォルトの名無しさん
2016/10/25(火) 20:33:02.00ID:DJibeu24 やっぱりTypeScript使いの人はMicrosoftマンセーの人が多いの?
Mac使いとしては.Netが使えたからどうなんって感じなんだが。
ElectronとかでTypeScriptを使う話をしてるの?
Mac使いとしては.Netが使えたからどうなんって感じなんだが。
ElectronとかでTypeScriptを使う話をしてるの?
484デフォルトの名無しさん
2016/10/25(火) 21:30:56.89ID:VLkXttsf Windows向けtypescript処理系自体jscriptにコンパイルされて.NETオブジェクト経由でファイルアクセスしてなかったか
485デフォルトの名無しさん
2016/10/26(水) 02:40:39.39ID:m/Az1cPZ >>483
>TypeScript使いの人はMicrosoftマンセーの人が多いの?
特定の企業が好きというよりかは
デファクトスタンダードに乗りたいだけ
WinとMacならWinが(価格性能比的に)使いやすいし
AndroidとiPhoneならAndroidが使いやすいから
(規制が少ないのでとくに開発側としては)
>TypeScript使いの人はMicrosoftマンセーの人が多いの?
特定の企業が好きというよりかは
デファクトスタンダードに乗りたいだけ
WinとMacならWinが(価格性能比的に)使いやすいし
AndroidとiPhoneならAndroidが使いやすいから
(規制が少ないのでとくに開発側としては)
486デフォルトの名無しさん
2016/10/26(水) 03:51:14.56ID:CrOhdQQd typescript使うよりc#で書くほうが楽だよね
487デフォルトの名無しさん
2016/10/26(水) 07:48:56.60ID:JLzF9ZGl >>481
JsProjectWinRTNamespace: https://msdn.microsoft.com/library/mt125480
WinRT (UWP) ならJavaScript側へ公開できるから、それを使うことは可能。
なんにせよ、JavaScriptホスト側を握っていれば (ChakraCore等) 好きにできる。Macでも。
JsProjectWinRTNamespace: https://msdn.microsoft.com/library/mt125480
WinRT (UWP) ならJavaScript側へ公開できるから、それを使うことは可能。
なんにせよ、JavaScriptホスト側を握っていれば (ChakraCore等) 好きにできる。Macでも。
■ このスレッドは過去ログ倉庫に格納されています
