TypeScript part1

http://www.typescriptlang.org/

TypeScript is a language for application-scale JavaScript development.
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
Any browser. Any host. Any OS. Open Source.

このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所

これは期待
VSだけじゃなく他のIDE用のプラグインも用意してもらいたい

言語そのものは、普通だと思っているけど、
Microsoftって、開発環境の品質はいいんだよ。

Visual Studioに自然な感じで統合されると思うな。

>>3
なんでMSがEclipseとかXcodeみたいなクソのためにそんなもんを用意せにゃならんのだ？

なんかさ・・・全然騒がれていないけどさ・・・これって・・これって・・・
と　て　つ　も　な　く　凄　く　ね　？
歴史が動く瞬間に立ち会っちゃったかも・・・

何が凄いのか全く分からん。

パッと見、相当凄いが

標準JavaScriptをベースにしているって所が
凄いじゃないかな。

すごさが全然わかりません
Coofee Scripterにもよくわかるように教えてください

コーヒースクリプトは
何もえるものがないからなぁ。
少し書き方が変わっただけ。

何も分かってない奴がとりあえず凄い凄いと言ってて笑える

>>11
https://twitter.com/ghoseb/status/25000171530

そもそも、coffee scriptやpythonにメリットなんてあっただろうか
とレスしようとして>>13で思い直した。
けれど、pythonみたいに空白インデントが構文な言語をhtmlに埋め込みたいか？

https://github.com/Coreh/katana
http://katanalang.org/

またまたnodeのつくりかけコンパイラ.
とおもったら…恩大の制作じゃないか！

s/恩大/御大/
http://detail.chiebukuro.yahoo.co.jp/qa/question_detail/q1216551072
おんたいだったし

https://npmjs.org/package/typescript
http://blogs.msdn.com/b/interoperability/archive/2012/10/01/sublime-text-vi-emacs-typescript-enabled.aspx

$ node -v
v0.6.19
$ npm install -g typescript

translates as follows:
http://developers.slashdot.org/story/12/10/01/2011201/typescript-microsofts-replacement-for-javascript
http://typescript.codeplex.com/

だんだん

「だんだんありがとう」が全国に伝播し、
日本海側、中国、四国、九州において方言として定着した。
定着する際に、西日本各地では「ありがとう」が省略されて「だんだん」のみで感謝

2000/12/07 南海日日新聞

これってC#で書いたコードをJavaScriptに変換できるようなもんなの？

JavaScript++で書いたものをJavaScriptに変換出来る
だからJavaScriptの糞な点がちゃんと改善されてるのか疑問

http://typescript.codeplex.com/workitem/49

出川哲郎曰く「やばいよやばいよ private の意味がほとんど成してないよこれ」

ﾜﾛｯｼｭwww

http://www.stevetrefethen.com/blog/TypeScript-what-was-the-problem-again.aspx
>In fact, there's an interesting parallel between TypeScript and Delphi where
>both require proprietary interface files to call functions in external modules
>with the same issues of getting these files generated/updated.

うーん外部モジュール呼び出すにしてコードの補完するにしても
つまるところ手書きのバインダが必要なのかな？

http://typescript.codeplex.com/discussions/397742
>Would it be possible to make the ".d.ts" files reference-able from normal ".js" files,
>such that we could get Intellisense and static type analysis even in existing JS codebases?

https://github.com/piersh/WebGL.ts/blob/master/WebGL.d.ts

いやー既存の、jsコードベースあるとしたら面倒そうだ
逆は簡単そうだけども。(typescriptのライブラリをjsから呼び出す)

>>22
何が言いたいのかさっぱりわからない

コミュ障なんだろそっとしといてやれ

node x typescript = answer

better java の C#に
better javascript の typescript か

java と名のつくものに怨みでもあるのかな
もう SUN は存在しないのに

そもそもJavaScriptが使いにくいのは型付けが弱いからであって
動的か静的かということはあまり関係ないような気がする。

JavaScriptは人類の負の遺産

JavaScriptに乗り遅れた人はJavaScriptをけなす

乗る前から潰れてるンだけど。

Javascriptおもしろいじゃん？

面白いと思うけど一度見下し癖ついてる人には難しそうだねー

Webアプリじゃないアプリは作れるのか？

>>33
sine

>>34 cosine tangent

JSのどこを見下すんだろう？
関数はファーストオブジェクトだし、Lなんとなかみに自由。
マクロは無いが。

JavaScriptってブラウザがいるんでしょ。おそいでしょ

三角関数も知らないガキか？
１００年早いんだよ

三角関数が煽りになると思ってるセンスがよく分からん

ブラウザにたよってると、ちゃんとよめないページになってしまうおそれがある

>>33
組込みの話ならお門違い
大体、世の中の需要のほとんどはwebアプリで事足りるでしょ

2chブラウザもwebアプリで十分だよな
エディタも音楽プレイヤーも

>>41 WSHとAPI呼び出しのサポートあればウィンドウアプリも作れるかもと期待してた。無理っすか？どうも有り難う

できるでしょ。これってトランスレータだろうから、winjsつかえば

C#作った人が作ってるのか
http://channel9.msdn.com/posts/Anders-Hejlsberg-Introducing-TypeScript
ヘルスバーグ神格化されてるなw

そりゃTurbo Pascal作ってDelphi作ってC#作れば神格化されるさｗ

googleも最近似た感じの言語作ってたけど、どっちがいいの？

素のJSじゃやってらんねーからいろんなところが代替を出してるんでしょうが。
Javaも似たような状態だな。

>>47
dartやgwtより、こっちの方が魅力的。jsのスーパーセットになってる。

口をそろえて言ってるが、噴飯モノだよなあ
そもそも使ってから褒めろよと

jsのスーパーセットで既存のライブラリも使えるから試そうと思うけれど、
dartなんて試そうなんて気すらおこらなかったよ

jsよりはdartの方が遥かに優れてるよ
だからjsのスーパーセットとか言われたら不安しかない

なわけない。dartなんてjava系統で動的言語の柔軟性なんて欠けている

http://typescript.codeplex.com/SourceControl/changeset/view/fe3bc0bfce1f#samples%2fnode%2fnode.d.ts

sample の node の機能を利用した例をみれば
haxeよりは 元の js のコードに近くはなる綺麗だけど
.d.ts ファイル必須。

http://www.typescriptlang.org/Playground/
playground だと
Unable to load reference
"$model1"
でエラーになるけどコンパイルには成功してるのかな？
コード生成されてる

コンソールからだとTypeError: Object #<Object> has no method 'existsSync'
でコンパイルできない。

https://github.com/madrobby/vapor.js/pull/60

各種ライブラリの port 待ち。さすがvapor.js

>>53
typescriptこそJava並なみのヘビー言語だから心配すんな

とうとう勝負を決する時が来たようだ、LL War

スクリプトなのにヘビーとはこれいかに

>>56>>57
いちいちコンパイルしないと使えないしLLじゃねーよ。糞言語

.net や jvm ではバイトコードを生成して環境差をそこで吸収してるけど
javascriptだと souce map というのがそれに当たるかな

直接ES3.1, ES4, ES5, ES6 向きの
生成コードを出力するというコンセプトはないと思う。まずは souce map に落としてそこで吸収する流れかと。

https://github.com/ryanseddon/source-map/wiki/Source-maps:-languages,-tools-and-other-info
source map generatorの使い方
http://d.hatena.ne.jp/gfx/20120408/1333892223

コンパイラの機能をリフレクションで利用したい
とか .net の ironpython やら ironruby で一時可能だったけど(windows環境以外で

さいきんはこんなかんじが流行なんかな
車輪の再発明という気も多少するが

Does TypeScript provide an explicit Public API for NodeJS Module Access?
http://stackoverflow.com/questions/12717309/does-typescript-provide-an-explicit-public-api-for-nodejs-module-access
http://gkz.github.com/LiveScript/

Livescript は coffeeの改良系の実装らしい…コンパイラ技法屋さん楽しそうやｗ

>>58
これを用いてJavascriptが勝利すると言う事だよ
馬鹿か？お前

Javascriptが糞すぎてどうしようもない

コンパイラまだーﾁﾝﾁﾝ

>>62
最新のブラウザにはJITコンパイラが入ってるから、単体のコンパイラなんか、もういらないと思う。

>>62
http://blog.markrendle.net/2012/10/02/the-obligatory-typescript-reaction-post/
zeh says:
October 2, 2012 at 1:18 pm
Re: classes ? one of the problems is that ES6 doesn’t seem to have a single
‘class’ standard. I haven’t gone that deep into the proposal, but TypeScript
seems to use the “Minimal classes” proposal
(http://wiki.ecmascript.org/doku.php?id=strawman:minimal_classes) not the main class one.

How final is Harmony’s proposal? It seems to be difficult to find information
on that. I hope Microsoft is not creating a new JScript.

Reply
zeh says:
October 2, 2012 at 1:20 pm
Actually, on second thought, TypeScript seems to use the “Maximally Minimal”
proposal instead
(http://wiki.ecmascript.org/doku.php?id=strawman:maximally_minimal_classes).

Ariya Hidayat ?@ariyahidayat
Need class and module? Use #Harmony and compile it
(same trick like in #TypeScript), see
http://ariya.ofilabs.com/2012/06/esprima-and-harmony-module.html and
http://ariya.ofilabs.com/2012/09/javascripts-future-class-syntax.html

コンパイラの前にまずはES6言語仕様の策定作業。
まだクラスの定義も定まってない。あくまでproposalの段階なのだ

Cは規格なんか決まる前にコンパイラ出たけど？

コンパイラってもう出てるよな？
こいつら何の話してんだ？

とりあえずCoffeeScriptとDartが一瞬でオワコン化したという解釈でおｋ？

あとはJavaScriptが「お前はクソだ。使い物にならん」と
四方八方からタコ殴りにされているという認識

長所：JavaScriptがそのまま通る
短所：JavaScriptがそのまま通る

Standard ECMA-262 5.1 Edition / June 2011
http://ecma-international.org/ecma-262/5.1/

C++/CLI 言語仕様書 西暦2005年12月 初版
http://vene.wankuma.com/ecma372/19_1_5_class_member.aspx#SS.19.1

typescript はプリプロセッサに近いものだから C というか C++に近い立ち居地。
ただこの web版 の C++ は現時点ではどれが正解とも云い難い。

https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS

結局デファクトとったとこ&さまざまな試みによる知見に元づく合意
その記法が標準になる

結局のところJavaScriptはそのままで普及しているので
それに準拠したやり方が最良なんだろうな。

JSしか書けないウンコプログラマだけが
JSで問題無いと思ってる

いろんな言語で幅広く仕事をしたが
結局のところ、言語の良し悪しは
大した問題ではない。

じゃあアセンブラで業務アプリ書いて

>>73が使った言語: Java, VB, Perl, PHP, JS

>>73
>>73が使った言語:??lisp,??c++,??c,??haskel,??c#

でもjavascriptで開発するとソース丸見えじゃね？

サーバーありきだからどうでもいい

クライアントアプリケーションでJavaScriptを組み込んで使えると便利そう
scheme 系とか組み込みで地味に利用されてる

でもエンジンのAPIが組み込めるように公開されてる訳ではないので
IE9以降がメインターゲットなんだろうかな

Qtscipt は ES3.1
http://qt-project.org/forums/viewthread/5381
ECMA-262 (5th|Harmony|next) で宣言された プロトタイプ の拡張はアリ？ナシ？
http://qiita.com/items/3a70b5a62b6c87379c77
JScript でサポートされる機能
http://msdn.microsoft.com/ja-jp/library/49zhkzs5(v=vs.80).aspx

How to call the compiler from .NET?
http://typescript.codeplex.com/discussions/397810

結局 MS Script Control でやれとなる。（当然エンジンはES3.1相当のJSctiptの構文のみが使える
エンジンは非公開だからなぁ…ブラウザ対応次第かと(特にモバイル

>>73
アセンブリャーからObjective-Cまでいろんな言語で幅広く仕事をしたが
言語の良し悪しは大した問題ではない（APIや周辺コミュニティのほうが重要）という通念を覆すほど
JavaScriptはクソ

以前からずっとバッドノウハウを量産して喜んでた界隈の連中を横目で眺めつつ
おかしいと思ってたんだよ。

LL言語マンセーだの動的言語マンセーだの喧しいからそういうものかと思ってたが
HTML5HTML5うるせーから仕方なく１ヶ月程度でキャッチアップしてみたら
お前らこんなどうしようもない言語と環境で仕事してたの、としか言いようがなくて

要はろくに大規模開発したことのない、レベルの低いJavaScripterどもが
駄サイクルを作ってたんだなという認識ですね。

機能もTypeScript登場で「JSの時代！」という無邪気なツイートを見かけたが、
CoffeeScript、Dart、JSX、Haxe、TypeScript、その他無数の変換言語↓
https://github.com/jashkenas/coffee-script/wiki/List-of-languages-that-compile-to-JS
これら全部現行のJavaScriptを否定しに来てるというのがまだ理解できないようでは終わっとる

JSが基幹言語？その逆で、ただの土管扱いされてるんだよ。
使いもんにならん言われてるんだよ。わざわざ新言語を量産してまで。

今回、あのHejlsbergにまでノーと言われたんだよ。

cにclassとinterfaceとgcとarrayとhash付ければ
それでよかったんだよ、IDEも豪華に対応できたんだよ
言語開発者はみんな余計な物付けすぎ

>>81
典型的な一ヶ月程度勉強しただけの
やつの感想ですねｗ

Javascriptはこんなクソコードが通るからゴミ


function f(x, y) {
    return x + y;
}
alert(f(1, "23")); # 123




なお、Typescriptで型を付けても通る（暗黙の型変換）

function f(x: number, y: string) {
return x + y;
}
alert(f(1, "23"));

C#でもJavaでも通るよ

https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Function/bind
http://kangax.github.com/es5-compat-table/

javascript 1.8.5とかガンガン攻める姿勢は買ったげる
でも ie8 軒並みアウトなんや

MSと違って規格がポシャったら互換性切っても怒られないからな

>>86
C#もJavaも糞言語じゃん

>>89
じゃあお前の好きなクソ言語の名前言ってみな。
それがクソかどうか判断してやるからさｗ

ドカタの判断 = 俺に使いこなせない言語はクソ

使いこなせないんじゃない。
ドカタ言語をあえて選ばないだけだ。

JSを使うくらいならTypeScriptを使ったほうがマシというだけで、JS以外の言語より良いという話ではないよ
それにまだ未完成品だし

言語の良し悪しは、言語仕様よりも、言語環境できまる。

実行環境の多さ、ライブラリの多さ、ノウハウの多さ、
書籍の多さ、提供会社の多さ、使用ユーザーの多さ、などなど。

それがわからない奴は、どうして良い言語が普及しないんだ！と
悩むことになる。

JSはバッドノウハウの塊だから決して良いとは言えない
ただデファクトスタンダードを取ったというだけ
これは市場が選んだわけではない。勝手に決められて嫌々ながらも従わざるを得なくなった
従いたくない人たちが魔改造を繰り返してる

バッドノウハウってなんのこと？

Perlでクラスを作るにはいろんな方法があります。
これがバッドノウハウです。みたいな話？ｗ

http://stackoverflow.com/questions/12756423/is-there-an-alias-for-this-in-typescript

lambda式内で this 参照はできないんかな…

>>94
言語が普及するか否かは、言語の良し悪しでは決まらない


普及する = 最底辺の馬鹿でも使える、が大前提だからね

>>98
言語を馬鹿にしているのか、
それを使ってる人を馬鹿にしているのか。
はっきりさせていい？

お前が馬鹿にしているのは、使ってる人であって言語じゃないよね。

普及した優れた言語。
それは馬鹿でも使えるが当然天才でも使えるんだよ。

お前が馬鹿にしているのは、天才が使っている優れた言語、ではない、

単に馬鹿でも使えることが、悔しいんだ。
なぜだろうねｗ

で、Javascriptは糞、ということに関してはコンセンサスとれてますよね。
まさかWeb2.0だAjaxだHTML5とかいうバズワードでノセられた奴が強弁してないよね。

>>100
お前がJavaScriptとライブラリをごっちゃにしてるってことはよくわかったよ。

馬鹿が言った言葉は、やっぱり馬鹿だってわかるなｗ

バズワードをガン無視してる俺かっけーｗ

無能すぎて食って行くだけで必死の奴は
仕事にありつけそうな言語使えば良いよ

デブでもおばはんでも乗れるママチャリが普及してるからって
ロードレーサーにママチャリ乗れっていう馬鹿はいない

近所のコンビニにライダーブーツ履いてNS400に乗って行くんだ

ところが原付になんでもやらせようとしだすから

Typescriptは原付を改造パーツでチューンナップしようって発想
改造しても所詮原付は原付

はっきりいって、c++とhtml5,jsだけで良いよね
実装が増える毎にVMの中のヒトたちが対応しきれない悪寒

お前よりもVMの中の人達は優秀。
対応しきれないのはお前だけ。

>>108
>>103

>>85
型付けても通るとかダメダメじゃん

組み込みの文字列連結がある言語なら一番普通の動作だろ

型付けてるんなら　x + y; の挙動は
コーディング時に明確に予測できるはずだから何の問題もないだろ
その程度の言語仕様も知らずに使える言語が欲しいってことか?

>>111
なんで通らないと思ったの？

>>112
え？

動的言語で普通この手の話で問題視されるのは「結果が予測できないこと」なわけで
yの内容によって文字列連結になったり数値加算になったりするなら問題だが
そうでなくて挙動が完全に予測できるんなら全く問題ない

暗黙の型変換の話であって
動的言語とか全く関係ないんだが

文字列とその他の+ではその他の方を
文字列に変換してから連結する仕様になっている言語はかなり多いからごく自然なことだが
暗黙の変換だろうが言語仕様知ってりゃ予測できるだろ

つーか、ただの演算子オーバーロードでは？

文字列.add(文字列）
文字列.add(数値）

addメソッドがオーバーロードされてるのと同じ事だろう。

型の問題っていうのは、互換性がない型、オーバーロードも定義さていないもの、
無関係のものを代入したら動かないのに、それが実行されるまで
わからないってのが問題なのに。

言語仕様の範囲ならどんな振舞いだって原理的に予測可能だわな

>>119
むしろ動いちゃうのが問題
>>85で引数に型指定しない場合だと、x, yの内容によって+の挙動が全く異なってしまう
さすがに+使うときは、文字列連結か数値加算かどちらか一方しか期待してないだろうから、
予期しない動作によるバグの原因になる。
型を指定するなら何の問題もない。

http://www.typescriptlang.org/Playground/

上で遊んでみたんだけど、まだ型推論は全然だね
こんなコードが通るし

function foo() : number { return 1; }
function bar() : string { return "23"; }
function baz(f, g) { return f() + g(); }
function hoge() : number { return baz(foo, bar); }

でもMSはF#を作れるところだし、今後に期待ってところか

それってC#で言えば
private var func(){...}
で型推論してくれよって話じゃないか。

>>122
型推論はAIじゃねぇよ。
どちらでも取れる問題の
正解を出せなんて不可能な話。

どちらでも取れる？
hoge()の戻り値はstring以外ありえんだろ

>>125
どこかでオーバーライドするかもしれんだろ。
windows.hoge = function () {return 123}

>>126
>>122でstring返す関数にnumberって型書いてエラーにならないのと
何の関係があるのそれ

>>126
それは無いものと考えないと静的解析の意味無い
ジェネリックには対応する予定らしいからもうちょっと型推論も強力にはなるんじゃないの

上はエラーになって下がエラーにならないんだから、もうね...

function f() : number { return 1 + "2"; }
function g() : number { return ((x,y) => x + y)(1, "2"); }

だんだんイチャモンになってきたな。

いやいや、間違った型を書いてもエラーにならないのは
型を全然書かないより邪悪ですから

さすがに型まで書いてるのに
数値の加算が文字列連結になったらびっくりするだろ

でも>>129のgの戻り値を使ったら、そういうことが起こる

>>132
お前、数値オブジェクトと演算子オーバーロードって
発想が頭にないんじゃないのか？

A + B というのは演算子 = メソッド と考えると
A.+(B) という形に置き換えられる。
お前が理解しやすい形にするとA.add(B)

つまりはこういうことだよ。
String ret = num.add(str);

たんに、数値オブジェクトのaddメソッドは
取りうる引数に、数値オブジェクト以外に
文字列オブジェクトに対応している。

どうでもいいけどアンダース的には演算子はインスタンスメンバじゃなくて静的メンバだよ

>>133>>134
で？それが

function f(x : number, y : number) { return x + y; }

においてfが文字列連結を実行しても良い理由になるの？

>>136
両方が数値の場合は、数値計算ですよ？
片方が文字列の場合は、文字列結合バージョンの加算が呼ばれます。

>>137
>>136のfの引数に>>129のgの戻り値を入れてみ？

>>97
Local "_this" silently conflicts in arrow function
http://typescript.codeplex.com/workitem/11

いちおう Issue Tracker に挙がってるけど

Capturing instance methods breaks 'this'
http://typescript.codeplex.com/workitem/127

this 周りは仕様に注意を要する部分ではあるとは思う

普通に数値計算されましたが？

C#で(int)(object)"1"とかやっても通るのと一緒だろ
動いちゃうのは問題だが

>>140
あほか。すぐバレる嘘付くなよ
g()は文字列"12"なんだからfに入れたら文字列加算になるよ
gの型注釈がnumberだから型エラーにはならないけど

>>142
バージョン古いんじゃないですか？ｗ

コンパイルオプションで実行時に型チェックするモードがあったほうがいいな
型推論をいくら完璧にしようが>>141みたいなのはどうしようもないし

>>143
バージョンwwwお前ばかすぎ

>>144
明示的なキャストは自己責任だと思うけど、実行時の型チェックは欲しいね

互換性のために仕方ないことでしょ。

そのうち、strictモードみたいなのでて
レガシーコードと呼ばれるようになるさ。

ようするにみんなの結論は
ベストではないが、ベターな言語なんだろ？

Javascriptよりはマシ

標準準拠で互換性があってベターなら使わない理由はないな。

別に普及しなくてもいいけどGoogleのDartみたいなバカだけでも潰してくれ

まだ様子見の段階

Dartよりはマシ

MSだからいつものようにボロカスに叩かれるかと思ったら
微妙な反応が多くて面白いなw
CofeeScriptやDartがいかにクソだったかがわかる

MSはプログラミング言語と開発環境には定評と実績がある

案外海外のほうがアンチMS的な反応が多かった。
どうせすぐハシゴ外すんだろ、みたいな。

それが一番当てはまるのはGoogleだろ
MSがIEに独自言語の処理系載せたりしたら永遠に外せなくなるぞ

ぶっちゃけDart発表時のほうが盛り上がってたよね
オプションで型チェック出来て素晴らしいって感じで

もっともダウンキャストに警告すら出さないと判明してから
そっぽ向かれたけど

Dartがそっぽを向かれたのはダウンキャストの警告とかが原因ではなくて、
良い言語だけど、乗り換えないといけない。つまり文法的に互換性がないということだろう。

TypeScriptにはそれは当てはまらなくて、将来のECMAScriptを
先取りしているから、JavaScriptの正統な進化版として考えることが出来る。

>>154
ヘルスバーグの名前が出てるからとりあえずみんな様子見てるんじゃないの？

(function (a, b?) => { console.log(a, b); })("a"); // OK
((a, b?) => { console.log(a, b); })("a"); // Errors
((a?, b) => { console.log(a, b); })("b"); // Errors
((a, b) => { console.log(a, b); })("a", "b"); // OK

悪くないんだけど、微妙に C# 独自の nullable とか this とか
アロー演算子合わせるとエラーに塗れる傾向はあるな
その辺なんか謎だわ

Nullable 型
http://ufcpp.net/study/csharp/sp2_nullable.html

http://code.msdn.microsoft.com/windowsdesktop/7-null-null-null-48ae7f82

nullable導入のおおまかな経緯はこんなかんじ。

何でNullがオブジェクトなの？
https://gist.github.com/2325537
Type(null) は Null 型だから Object ではないってことですか。typeof とは違うんですね。
http://togetter.com/li/300821
http://wiki.ecmascript.org/doku.php?id=harmony:typeof_null
https://gist.github.com/887049

しかして typeof が理解に苦しむ
ほんとは null はオブジェクトとして扱いたくないんだけど

実際のとこ至るところでYou、typeofでObjectt判定しちゃいなよ
してるから null はオブジェクトみたいに扱われてるんだなと…

>>159
Dartを良い言語と言ってる時点で
Java, JS, Perl, PHP程度しか使った事が無い
ドカタまるだしなのが分かる。
もうちょっとマトモな言語も使ったら良いよ。

マトモな言語教えてください

VB

>>72
jsだけで飯が喰えるのに、いくつも言語おぼえる必要があるなんて
2次請け、3次請け以下の大した技術力のない奴隷商に飼われているとしか思えない。

むしろjsの仕事なんてドカタ仕事しかない

また苦しくなったらドカタかｗ
よっぽど都合がわるいんだろうなｗ

他人が薄給ドカタ仕事を引き受けてくれるのに
何の都合が悪いというの？

>>166
底辺の奴らだけが、奴隷市場の流行に合わせて
Java, VB, PHP, JavaScript 等を覚える必要がある

>>169
いや、単純にじゃあドカタじゃないやつは
なんて呼ぶの？って話だよｗ

週40時間労働、年収800万以上でプログラマを名乗れます
それ以下はドカタ

>>172
ダウト。それだと学生プログラマは存在せず
学生ドカタということになってしまう。

え？文脈的に働いてる人の話だって分からない？
ドカタに文脈なんて無理かー

>>173
え？お前が書いた>>166って学生も対象にしてたの？

プログラマとドカタなんて俺からみたら違いはない。
喧嘩せずに仲良くやりなよ。
そんなことよりtypescriptでひとつなんか作って公開してみて
作った感想でも披露してみないか？

>>175
常識でわかるだろｗ

常識で分かります。>>173が馬鹿だってことが。

なんで2ch掲示板ってこうなるんだろ
匿名だからでは説明できない。redditと比べても明かに低レベル
日本人の資質か

日本人の資質だからでは説明できない

反応の速さにこだわるから
即答できなければレベル高くても失格という風潮

推すのは得意というか
でも肝心要で引き際を誤る

そしてデスマへ。責任論を巡って議論。
このパターンはとても多いと思う

ここは全部自演も余裕だからサンプルにはならんけどね

>>179
それ、比較対象がおかしくね？4chが妥当

>>184
4chはふたばだろアホ

　　　　　　　／/
　　　　　／　 /　　　ﾊﾞｶｯ
　　　　 //⌒)∩＿＿∩
　　　　/.|　.| ノ　　　　　ヽ
　　　 /　|　| 　●　　　● | 　　　　
　　　/ 　|　彡　　( _●_)　ミ 馬鹿には無理
　　 /　　|　ヽ　　|∪|　　/＿
　　/／　│　　　ヽノ　　＼／
　　"￣￣￣￣￣￣￣（..ノ

まあIT関連のニュース記事やブログ記事も日本語のやつは平均的に劣ってるからな

平均が優秀ではないのは当然です
まず基本的なことから始めないと最先端のニュースも扱えません

基本的な部分がダメだから言ってんだろｗ

別に内容の難易度で優劣付けてないわ。質だよ質

量ではなく質なら優秀なやつが数人いるだけでいい

よくそんなズレた頓珍漢なレスできるな

言語に優劣がある
のではなく
ただの馴れと慣習による部分が大きいだけだ。流儀は場所によって変わるのは当然

現実に言語には優劣がある
ただしそれは一方の角度から見た場合の優劣であって
別の角度から見ればまた違う優劣が現れる
すなわちVBは馬鹿用なのでRubyより劣るとしても
速度ではRubyの方が劣っていたりする訳だ

rubyとかすかしたかっこつけたい奴が使ってるだけでしょ
VBAでいいじゃん

29 デフォルトの名無しさん [sage] 2012/10/10(水) 18:11:39.35 ID: Be:
    http://www.infoq.com/jp/news/2012/10/Ruby-on-Rails-Node-js-LinkedIn

    LinkedIn は先日，パフォーマンスとスケーラビリティを理由として，
    同社のモバイル用バックエンドインフラを Ruby on Rails から Node.js にリプレースした。
    これに対して元 LinkedIn のチームメンバが，何が問題であったのか，自身の意見を表明している。

30 デフォルトの名無しさん [sage] 2012/10/10(水) 18:15:24.99 ID: Be:
    ・優れたパフォーマンス – いくつかのシナリオにおいて，Node.js は Rails の20倍以上高速だった。
    ・サーバ30台の処理をわずか３台で実行できるため，10倍以上のトラフィックを処理する余地が生まれる。
    ・フロントエンドの JavaScript 技術者をバックエンドコード開発に従事させることが可能になる。
    　この結果，２つあった開発チームが１つに統合された。

じゃあ、初めからNode.jsでやっときゃ良かったのに、
って話でも無いんだろうな。
サービスを色々試行錯誤する分にはRubyの方が楽だったのかも。

railsとnode.jsって用途ちがくね？

>>154
> MSだからいつものようにボロカスに叩かれるかと思ったら

もはやそんな時代じゃないしな。
Mozillaあたりの連中はMSガーMSガー喚いててて笑ったけど。

ボカロスに叩かれる

あとは、今はECMAScriptのスーパーセットだとしても
どっかで互換壊れてまうだろとJavaScript原理主義者の指摘
俺の答えは、それがどうした、ですかね。ゴミ言語JavaScriptなどぶち壊せ。捨てろ。

むしろECMAScriptがTypeScriptに合わせろ
っていうかもし互換壊れて大きな問題になるほど普及すれば必然的にそうなるだろうし

これでスマホアプリ作ってみようかな
JavaScript互換だから手軽に始められるのはいいね

NodeからJavaScriptちゃんと見たけど良い言語じゃん、大規模開発に向かないだけで。それをTypeScriptが補完してくれるんだから最強だね。

完全に型注釈付けるのを強制するか、ちゃんと型推論してくれるなら
JSの型付けの弱さを克服できるんだがなぁ > TypeScript

javascript で template programing とか誰得

>>205
コード書く側が意識してりゃ済む話だろ

意識してりゃ済む話なら型チェックなんて要りません

間違いを一個だけ探すなら意識するだけで済む
百個ぐらい溜まってからまとめて探すなら型チェックが必要

インテリセンスを自力で実装した事のある俺に言わせて貰うと
型の省略は開発ツール開発者に恨みでもあるのかというくらい酷い
分析ツールを走らせるための情報が圧倒的に足りてない
型推論なんて言語開発者のオナニーだからやめてくれ

開発ツールの開発者がヘボいとJavaみたいに同じ所に二回も三回も型名を書かないといけないわけか。

>分析ツールを走らせるための情報

その辺はおいおい言語の成熟と共に出揃ってくるもんなんじゃ
日本語と広辞苑の編纂作業みたいな一度解体する作業は不可欠や

そりゃ「補完」の情報を渡すべき所に「型」の情報を渡せば間違いも起きるわ

インテリセンスが型推論すれば良いだけの話だ罠

>>214
型推論じゃないよ補完は名前を推定するんだよ

補完よりキータイプ速い漏れは勝ち組
っつーか補完機能なんて邪魔だろ？

ドカタの発想だな

>>216 同意
つうかタイピング遅いやつ多すぎ

>>215
アホか。コンパイラが型推論できるんだから
インテリセンスだって型推論で型情報を得られるだろ

型が省略されてるから名前の補完ができませーん < アホ

型推論は完璧じゃないよ。

たとえば変数Aがあったとき、
この型を推論できる言語はない。

お前は何を言ってるんだ

場合によっては型推論があっても
型注釈を必要とするケースはあるが、
低能さが文面から滲み出てる>>220が考えつく程度のコードなら
型推論できると思うぞ

function(x,y,z){return x===y ? y : z;}
x,y,zの型は同じ
同じならnumberでもstringでもなんでもいい

VB、C#、F#、C++/CLI、F#、Powershell、TypeScript
MSの言語設計センスは神懸ってるよな
玩具のSmallBasicですら非常にバランスのいいちゃんとした言語だし
どっかのGoogleとはえらい違いだ

型を二回書くだけでツールがいろんなことをやってくれる
クラスやメソッドや引数の細かい情報までを
キー一押しまたは何もせずに表示してくれる
これほどすばらしい機能は他にないよ
君らは天才だから膨大な量のリファレンスを丸暗記して
書いたクラスのメンバの引数までも完全把握してるんだろうけど
俺みたいな凡人は記憶力弱いから無理なんだよ
言語開発者も天才ばかりだから俺みたいな凡人の苦労はわからない
凡人向け開発ツールを天才たちは作ってくれないから自分で作るしかない
だからこそ型情報を全力で守らなければならないのだよ
型を軽視する言語は天才にしか扱えないんだよ

<T>を軽視する言語は今すぐ<T>を追加しろー

Playgroundって開発環境として提供されないのかな
デモ用にしておくにはもったいない出来

googleの言語、開発ツールは２流だよね

>>223
http://www.typescriptlang.org/Playground/
function fn (x: number, y: number, z:number) : number {
return x===y ? y : z;
}

alert(""+fn(0,0,7));

呼び出す側での型キャストもどきが必要になるから
あんま使い勝手良くならないんだと感じる…
型はあるんだけど、それを演じて示す prinf にあたるものが欠けてるような

>>223
多相型も知らんの？馬鹿ですねー
それくらい楽勝で型推論できる

function<T>(x: T, y: T, z: T){return x===y ? y : z;} だな
ジェネリックは早期に導入予定

interface console {
time(obj:string);
}

visual studio 上で（playgroundだと再現できない）
console オブジェクトの足りてないメソッドをコード中で追加

そして補完を試してみると
なかなか壮絶な候補が現れた…
と

いうほどジェネリックとかは簡単じゃない

使い方が間違ってるだけ。consoleはフィールドなのにinterfaceとして
宣言するのはおかしいと思わないのか?
フィールドに型を付けるにはdeclare varを使うけど、TypeScript組み込みのと重複するから
追加したかったらTypeScriptのlib.d.tsを編集する必要があると思う。

そんなには、間違ってないよ。
ArrayとかConsoleとかFunctionとか、組み込みオブジェクトは
interfaceで定義されていて(lib.d.ts)、同名のinterfaceを定義することで
拡張することが可能になってる。
たとえばjQueryプラグインはinterface JQueryを別途作れば足せる、というようにね。

ただ、組み込みクラスに対する拡張は挙動が変(Consoleに限らずArrayとかも)で
これはただたんなるバグなので次版では直してくるでしょう。

ちょっと触ってみたけど
構造的部分型を採用してるとこはポイント高いね

VSのプラグインって動作が怪しいねえ。
インストールするとVSが起動時に例外をスローして落ちるようになった…

http://stackoverflow.com/questions/12869055/does-typescript-support-touchevent

ある意味 interface を多用する傾向があるのか
書いてるとたしかに定義したくなるのはわからんでもない

入れ子になってるかんじの interface とかこれは
w3c の draft からしてそんなかんじなのか…

http://www.w3.org/TR/2011/WD-touch-events-20110505/

https://github.com/scripted-editor/scripted

どうせ裏で node.js 使うんなら
transcript の変換ステップを間に挟まない
こういうのも結構ありか

http://dist.springsource.org/release/SCRIPTED/Scripted2.mov

フォントを変えるところで .scripted ファイルいじるあたり
おもわずワロタｗ

http://sourceforge.jp/magazine/12/10/15/0559236

そんな事よりDartしようぜ！

TypeScriptの変換後のJavaScriptコードの美しさを見たら
Dartなんかクソほどの価値もないことがわかる

TypeScriptは、JavaScriptは中間言語とか抜かしてる馬鹿へのアンチテーゼ

JSはネットのbytecodeか？
http://brendaneich.github.com/Strange-Loop-2012/#/

>>242
JSがとんでもない言語になりそうな予感・・・
読んでてちょっと笑ってしまったｗ

お花畑すぎて吹いた

TypeScript　基本的には好きなんだが、もう少し、記述方法に制限を掛けて欲しかったね。
この言語仕様だと、いろいろな表記が可能だから、プログラムが読みにくくなりそう。

JavaScriptが通らないといけないという大前提があるから仕方ない

Web以外で使いたいから、int64_tに相当するのも欲しいけど、
Javascriptにコンパイルできなくなるしな。

Dartみたいに糞JavaScriptを吐いていいならエミュレーションで実装できるよ

プログラムファイルに、#lang r6rsみたいに書き込んで
文法チェック切り替える言語もあるね。

PowerShellをTypescriptで置き換えよう（回帰）

モジュールの下に宣言したインターフェイスを
モジュールの外のクラスで実装するにはどうしたらいいんだろう

高度に発達したプリプロは言語と見分けがつかない

>>242-244
一応言っておくが、ブレンダン・アイクは
オリジナルのJavaScript(当時livescript)の開発者だぞ

JavaScriptがこれほど使われてるのはJavaScriptが言語として優れているからでは決してないし
むしろクソ言語を生み出した元凶じゃないか

クロージャがなければ即死だった

組込み言語だけど表現力もあるし地雷原もある素晴らしい言語。
JavaScript 「再」入門
https://developer.mozilla.org/ja/docs/JavaScript/A_re-introduction_to_JavaScript
JavaScript Garden
http://bonsaiden.github.com/JavaScript-Garden/ja/
Googleスタイルガイド
http://cou929.nu/data/google_javascript_style_guide/
構文は簡潔ではあるよね。

こんだけ普及するとこれを思い出さずにはいられない
http://monobook.org/wiki/Bjarne_Stroustrup_%E3%82%A4%E3%83%B3%E3%82%BF%E3%83%93%E3%83%A5%E3%83%BC

>>254
言語としてはそれほど悪くないよ。
Perl, PHP, VBと比べたら天使が舞い降りてきたみたいなもん。

まあブラウザ上は非互換や過去の遺物で悲惨みたいだけど。

>>255
もともとSchemeを導入する予定だったから、
クロージャ無しで設計されるのはありなかったな。

>>258
天使とか言い過ぎだろ。
どちらかというと、馬鹿と鋏は使いようって感じだ。

普通のスクリプト言語としては悪くないと思うが、
>>242で妄想してるように中間言語として使うなら明らかに失敗でしょ
数値型がdoubleだけとかありえん

普通のスクリプト言語としてもウンコ > 数値型がdoubleだけ

>>262
数値がdoubleだけってまじかよ。ありえんだろ。

luaとかもそうだよ
32ビットに収まるうちは整数の誤差は出ないから大して問題ない
中間言語としては終わってるけど

だよな
いまどきfloatとの使い分けくらい出来ないとな
ほんと腐ってるよ

CのプログラムもJavascriptに変換してブラウザで実行出来る時代だぜ。
Emscripten + Chromeより速い言語処理系作れる奴なんてほとんどいないぜ？

それで速いなら組み込みのshortとかlongとかfloatとか使えたらもっと遥かに速いぜ?

GoogleのDartだってそういうのいちいちエミュレーションするのアホらしいから
独自のVMを搭載してるのに

既にJITに全て任せる時代。

NaClですね

>>269
JITに任せたらJSでエミュレーションしてる64ビット整数の演算がハードウェア命令になるのか?w

JavaScriptを中間コードとして使うときのコードの出力の仕方を標準化してしまって
それに基づいて処理すれば完璧な最適化が可能だろうけど
それやるとJavaScriptの意味が皆無だからな
JavaScript無関係に新しくWebVMみたいなのを策定して載せるのと何も変わらない

一度Emscriptenのコードを読んでみると良い

NaClですね

>>273
思いっきりエミュレーションしてるがな
add一つに何行コード書いてるんだよw

floatやshortはまだ我慢できるがbyte/int32/int64が無いのはだいぶ辛い

unsignedも無いの？

unsignedはいらんよ
実質同じなんだから

>>276
ランタイムの実装依存だけど、TypedArray あるじゃん

int32はあると思っていい

実用上はint32はあると思っていいけど
オーバーフローしたら勝手にdoubleに化けたりするから
中間言語として使うのであれば結局単純に+をJavaScriptの+に変換するわけにはいかない罠

>>281
元の言語でのオーバフローしたときの挙動と同じでなければいけないってこと？
それなら、たとえJavaScriptにint32が存在してたとしても、
そのint32のオーバーフロー時の挙動が元の言語の挙動と違う可能性があるんだから、
そのまま+をJavaScriptの+に変換できない可能性があるってことになるよね？

>>281
中間言語とかなぜ出てきたかわからんが、厳密に規約でビット長他決められてるやん

このスレでなぜ出てきたかわからんというのがわからん

使ってみたいからExpressにプラグイン入れたんだけど
新規ファイルでtsはでてきたんだけどソースの色とか変わらないのは仕様なのかな？
Expressだと駄目？

Express for Webで使えてるけど

あれ？じゃインストールに失敗してるのかもやり直してきます
ども

別の人だけど、VS Express 2012 for WebにTypeScript for VS 2012入れたら
新しいプロジェクト➡テンプレート➡VisualC#➡HTML Application with TypeScript
というのが出てきた。

JavaScriptのようなクソレガシーに今後10年しばらく好き放題されると思うと
うんざりするから、.NETあたりにでも頑張ってほしい(´・ω・｀)
速度特性のまったく読めない動的言語を基盤にしようなどと言い出した連中を死刑にしたいマジで

>>266
> Emscripten + Chromeより速い言語処理系作れる奴なんてほとんどいないぜ？

Emscriptenが速いなんて勘違いがどっから出てくるんだよ。
つかChromeではさらに遅いぞ。作ってるのMozillaの中の人だから全然Chromeに最適化されてねえ。

だいたいLLVM→JavaScript変換なんぞまわりくどい真似やってる暇があったら最初からネイティブで出すわｗ
特にMozillaがドヤ顔でデモってるような3Dゲームとかさ。
（あれオリジナルの10倍フレームレート低いらしいな）

C++や他の言語でもマルチ開発ができる、
実際多数のアプリケーションがやってるということが最近忘れられがちっつーか
ウェブ界隈の連中は最初から知らないんじゃねえかとすら疑ってる(´・ω・｀)

PC以外もターゲットにするならネイティブ(Monoみたいなのも含めて)の方が
ずっとクロスプラットフォームだしな

まあ今後はJavascript優勢になるのは間違いないよ。

Googleさんが全力で阻止してくれます

>>289
黙れクズw
悔しかったらブラウザウィンドウ上で動くJSより素晴らしい言語とやらを作れよw

CIL

lljs.orgですねわかります

今時何にそんな速度が必要なんだ？お前ら

ChromeOSですよ、お前さん。

死ねゴミ共が
死ねゴミ共が
死ねゴミ共が
死ねゴミ共が

a

すっかり勢いなくなったな。
使ってる奴いないのかな

goのときと同じ流れ

書いてるが良くも悪くも普通
ある程度の規模になりそうなコードに使って素のJSよりいくらか楽になるくらい

個人的には好きだけど
Javaっぽい文法なんで、C#、ActionScript、Java、Haxe辺りは変換できそう
そういえば、ABAさんがそんなことを書いていたような

>>290
>だいたいLLVM→JavaScript変換なんぞまわりくどい真似やってる暇があったら最初からネイティブで出すわｗ
既成コードの使いまわす為だろうし、
まともなクロスプラットフォームなツールなんて実際のところjavaしかない

(ﾟ∀ﾟ)ｱﾋｬ
http://www.sellsbrothers.com/posts/Details/12724

Win8ストアアプリでTypeScriptはないだろう。C#でいいわ。
Node.jsベースでTypeScript用のMVCフレームワークとかの方が受けると思う。

>>297
> 今時何にそんな速度が必要なんだ？お前ら

お前それサバンナでも同じ事言えんの？
たとえばこういう仕事をしている開発者たちの前で↓

スクエニ、「スクウェア・エニックス オープンカンファレンス 2012」。「Agni's Philosophy」の舞台裏を明らかにする“技術編” - GAME Watch
http://game.watch.impress.co.jp/docs/news/20121129_575412.html
4Gamer.net ― 次世代ゲーム機のグラフィックスはどうなる？ CEDEC 2012 ゲーム開発マニアックス〜グラフィックス編
http://www.4gamer.net/games/032/G003263/20120929009/

他にも科学技術計算だのビッグデータ（）だの
いくらプロセッサをフルにぶん回しても全然足りんような分野がまだあるだろ。

正直、コンピュータの速度はもう十分だの、HTML5がnative置き換えるだの言う奴らは
その程度の仕事しかしていない、とまでは言わないにせよ
まだまだ解決するべき大きな問題が存在すること　す　ら　も　知らないのがバレバレなんだよなーと
憐憫の目で見てる(´・ω・｀)　視野せめぇ。

>>307
C#は興味深い流れになっとるよね。

nativeの世界には、CPU全コアフルロードになるコード書いて
タスクマネージャ眺めて喜んでるような変態がいるんだぜ(´・ω・｀)

暇人乙

>>308
> HTML5がnative置き換えるだの言う奴らは
> その程度の仕事しかしていない

それも視野狭窄だわな。

科学技術計算なんてループぶん回して配列にアクセスしまくるだけなんだから
スクリプト言語くらい楽に書けて普通のネイティブコードが吐けてFortranと同じくらい速い言語があってもいいのに
Fortranに対するTypeScriptみたいなの作れないかな

Fortressとかx10とかあるじゃん

TypeScriptで分数クラスを作ってみた。
楽しい。

gist.github.com/4520496
書いたソース。
忍法帳ってなんだこれめんどくさい。

TypeScriptで演算子のオーバーライドって実装されるんだろうか？

Andersは演算子は対称であるべきだからstaticにしろ派だから難しいんじゃないかな。
現に、インスタンスメンバにするのが自然な()や[]には対応してる。
手っ取り早く実装するなら+などもインスタンスメンバにするのが楽だけど、それは気に入らないんだろ。
でもC#みたいにクラスメンバにすると静的解析に依存することになるから、
オペランドの型がコンパイル時に分かってる場合と分かってない場合で
演算子の動作が変わってもいいのかとかいろいろ問題がありそう。

仮にインスタンスメンバでも、
hoge + 1 (TS) を hoge.opAdd(1) (JS) に変換するのはhogeの型がプリミティブ型でないことが
静的解析で分かってるならいいけど、分からない場合は hoge + 1 (JS)にするしかないから
結局静的解析の可否で挙動が変わってしまう
無理だな

即時関数の書き方教えて

その辺の非tsな外部jsを読み込むこととかできるの？

>>319
(()=>{alert("a");})();
>>320
普通にできるというかtsから変換したjsと普通のjsを普通にHTMLのscriptタグに並べるだけ
型チェックを活かしたいならインターフェイスを定義する

>>321
さんくす！後でやってみる！

typescriptを使うことでどのくらいコード量が減るかサンプル見たいのかける天才いる？

>>323
コード量はそんなに変わらんだろ？
CoffeeScriptなんかとは違うんだぞ。

公式ページのPlaygroundのサンプルコードで十分だろ。
TypeScriptが吐くコードは人間が書いたのと見分け付かん。
コード量はそう変わらんがJavaScriptでクラス作るときの
変なバッドノウハウによるノイズが無くなる。

ヘルスバーグもここまでか、、、

仕様策定はまだ続いてるが、既にMSのJavascript開発で
工数削減に役立ってるってのがすげーよな

こんなのがでてたのか・・・
javascriptは毛嫌いでやらなかったが、これならおぼえたいと思ってしまった。

>>321
Supplied parameter do not muchなんちゃらってなったよ……

WebGL.d.ts
Three.d.ts
既にあるな
考えることはみんな同じなんだ

アンダース氏が設計した新言語による次世代JavaScript開発とは？
http://www.atmarkit.co.jp/ait/articles/1301/18/news087.html

Visual Studio 2012 入れなくても使えるようになったら使う

Node.jsで動くコンパイラとemacsプラグインが提供されてる

そもそもTypeScriptはNodejsで動かすものであってVisual Studio 2012対応はついで。

>>308
本当に簡単なレベルのことで金儲けできた方がいいじゃない
そんなにプロセッサをブンブン振り回したりしたら、地球環境に優しくないよ
その昔、ファミコンレベルの演算能力で月まで行けたんだから、
もっと低次元なレベルで解決できる問題なんて沢山あるじゃない

ていうか、5年ぐらい前ってM$のIEがweb屋たちに叩かれまくってよね

>>333
ありがとう
それなら手を出してみる

typescriptのサイトのget itページ行けば、node.jsの方が先に書いてあるんだけどな。

UTF-8 で書いたソースで
console.log('漢字');
を Windows の cmd.exe で実行すると
cp932 で出力されてるっぽいんだけど
どこで何が行われているの？
日本語の扱いは良きに計らってくれるの？

誤爆？

http://d.hatena.ne.jp/ishikawam/20120410/p1

モジュール化って可能なん？
AMDみたいのはいやづら

>>342
モジュールの定義には対応しているが、Javascript自体に存在しないので
Javascript上でよく見られるモジュール定義もどきとして書き出される。
node.js互換の形で。

TypeScriptは結局JavaScriptの問題を解決してないから萎えた。
ECMAScriptもだが、特にmodule、あれで大規模開発が可能だと本当に思ってるのか。

> 3. 次に挙げる ES4 の提案の一部はウェブでの利用において不適切と判断されたので、
> 今後二度と議題として取り扱わない。パッケージ、名前空間、早期束縛。この決定が
> Harmony の肝である。

つくづくバカな決定したなこいつら。

正直、断言するけどActionScript＝ECMAScript 4ルーツのHaxeを使ったほうがいい。

TypeScript クイックガイド - phyzkit.net
http://phyzkit.net/typescript/

> この b2Vec2 クラスを使うときは、
>
> var v : Box2D.Dynamics.b2Vec2 = new Box2D.Dynamics.b2Vec2();
> のようにかけます。ただこのままではすべての場所で完全名でクラスを参照しなければならず、面倒です。
> そこでクラスのエイリアスが欲しくなるわけですが、JavaScript のように単なる変数としてエイリアスを
> 定義してもうまくいきません。
>
> // b2Vec2 のエイリアスのつもり……
> var b2Vec2 = Box2D.Dynamics.b2Vec2;
>
> // コンパイルエラー。b2Vec2 というコンストラクタはあっても b2Vec2 という型はない
> var v : b2Vec2 = new b2Vec2();
> コンストラクタの呼び出しだけならできるのですが、b2Vec2 は単なる変数で型の名前空間にあるわけではなく、
> 型注釈の位置では使うことができません。かと言って直接クラス名のエイリアスを定義する機能はないようです。
> このような場合、import キーワードでモジュールのエイリアスを定義することはできるので、これを使うと
> 少しは楽なのではないかと思います。
>
> import B2D = Box2D.Dynamics;
> var v : B2D.b2Vec2 = new B2D.b2Vec2();

これを読んでTypeScriptは却下した。アホだろ実際。癖のなくなったCoffeeScriptでしかない。
なおHaxeは普通にimportすればnew b2Vec2()でおｋ

あとはこれも萎え要因

https://sites.google.com/site/jun1sboardgames/programming/typescript_module
> 「/// <reference path="" />の参照指定はあくまでもコンパイル時のもので、
> 実行時の依存関係の解決は君自身の責務だよ」

>>344
大規模開発支援より既に広まってる処理系群との互換性が大切
というのがECMAScript、というかアイクの公式見解。
ただ将来的にECMAScript 4の方向が否定されたわけではない。

>>343
それがAMDだ

>>345
こんなふうには書ける。
module M
{
　export interface P { x: number; y: number; }
　export var a = 1;
}
var p: M.P; // Used as ModuleName
var m: M = M; // Used as TypeName and PrimaryExpression
var x1 = M.a; // Used as PrimaryExpression
var x2 = m.a; // Same as M.a var q: m.P; // Error

そもそもnode.jsは自前でmodule機構を持ってるから大して困らないよ。

CofeeScript のスレはありますか？

聞く前に検索ぐらいしろ

>>348
TypeScriptのこと何にも知らないけど、一つだけ言える。

そのコロン、キモイ。

>>351
プログラミング言語を能力でなく感情でしか語れないのは悲しいね。
少なくともJScript.NETよりは遥かにスマートだと思うよ。

>>352
> var m: M = M;

俺には無理だわ。

きもっ

>>353
お前の個人的な感情とかどうでもいいんで。帰って。どうぞ。

個人的な感想ということにしたいんですね

>>348
pascalみたいや

俺もTypeScriptは知らんけど、「変数名 : 型」「変数名 : 型 = 値/interface closure」あたりまでは想像できるが、
var m: M = M;の意味がわからんな。

書いてて楽しくない言語は駄目だ
Matz

Rubyは書いていて楽しくない。
単純な誤字脱字がその場で検出できない。

実行してエラーになって初めて認識できる。
その頃には違うコードを見てるから
くだらない誤字脱字の場所を探さなければならない。

Rubyは楽しくない。
簡単なリファクタリングでさえ神経を使う。

範囲を選択し、場所を移動する。
頭ですぐに思いついたことを
すぐに実行できない。

プログラミングの大部分が
コードを右から左へ動かすことに終始する
ダメプログラマにとっては死活問題だね。
そういうウンコプログラマ用の言語じゃないんだRubyは。

var m:M = M;の後ろのMはMのsingleton moduleになるらしい。
そう定義されたmも同じ。だからm.aはmoduleローカル変数のように振る舞う。

>>362
ダメプログラマ御用達のRailsがなかったら消滅してる言語のくせにw

node.js + coffeescript + express で Ruby も Rails も要らなくなりそうな悪寒

node.jsはウェブサーバーとしてはまだサーバー全体が
死ぬリスクが高いから商用としては微妙だけど、
C4K問題が発生しない設計だから
汎用じゃなくて専用のサーバーとしては十分ありだよね。

大規模なソフトウェアこそTypeScriptが生きる。

> node.jsはウェブサーバーとしてはまだサーバー全体が
> 死ぬリスクが高いから商用としては微妙だけど、

それそうとう技術力低いだろｗ
例外の使い方の基礎さえ知ってれば
落ちることはない。

あ、例外の基礎を知ってるっていうのは、
try-catchは必要最小限で十分ということを
知ってるって話な。

俺、try-catch使えるぜ！って感じで
やたらめったら入れる奴は
基礎がわかってない。

ONERRORGOTOですねわかります

nodes.jsが単一プロセス、単一スレッドで動いてるから
プログラムのミスや例外などで処理が止まるとサーバー自体も止まるという話なだけ。

nodejs側の問題なのでTypeScriptとは直接関係ない。

例外処理ちゃんとやってても落ちるもんは落ちる
ましてC++で拡張できたりするんだし

Windows8 64bit、VS2012 Express for Webでプラグイン導入できた人いる？
インストールしてもテンプレートに出てこない。。0.8.1.1、0.8.2で試した。
ちなみにWindows7（32bit）ではうまくいった。

ごめん解決した。
昨日0.8.3がリリースされてたみたいで、それ入れたら出てきた。

以前の奴でもインストールされたとこにあるプラグインを自分でクリックすれば
インストール出来た

Eclipseで使える？

Rubyが楽しいってデマ誰が広げたんだろうね

ｵﾚ

クラスを定義するときに同名のクラスが宣言されてるのはNGなの？例えるとこんな感じなんだけど
declare class Test { constructor(); }
class Test { constructor() {} }
下のコンストラクタで次のエラーが出る
Malformed function body (is this a class named the same as an existing interface?)

宣言ソースに必要なもの全部まとめようかと思ったんだけど、これがひっかかる

エラーメッセージが不親切だけど、基本的には単にクラス名の衝突だと思う。
class Test { constructor() {} } をコンパイル単位に含めるなら、
declare class Test { constructor(); } は必要ないよ。
それかもしかして C/C++ プロトタイプ宣言みたいな使いかたしてない？

>> 376
彼らは typo したり runtime error 出したり、半年前に自分が書いたコードが読めなくなって全部書き直したり、
クソ遅い処理系にほとんど意味のない最適化を施すのが、楽しくて仕方がないんだよ。
我々には理解できない性癖だけど。

>>379
.d.tsファイルの仕様的に、C++っぽく使えてもいいのになぁっていう感じでした
別にエラーにしてくれなくてもいいのに。C++だってリンクするまでは衝突するかどうかわからないんだし

>>381
TypeScript の declareは、C/C++ のプロトタイプ宣言というより extern に近いものだからね。C/C++ でも

extern void hoge(void){}
void hoge(void){}

が衝突するのと似たような理由だと思う。

あっ違うわ　
extern void hoge(void);
void hoge(void){}
は別に衝突しないや
最近 C/C++ 使ってないから忘れた

>>378
TypeScriptにおけるdeclareというのは
コンパイルするソースコード中にその定義が含まれない（既に外部で定義されている）ことを意味するから、
そのソースコード中にその実体を定義するのは言語仕様上矛盾している。

HTML5デモ「日本全国花粉飛散マップ」を作って分かった
CreateJSとTypeScriptでの効率的な開発手法
ICS LAB
http://htn.to/7m1sEe5

javascript全く知らないんだけどtypescriptから始めても大丈夫？

大丈夫

情報が少なくて大変なだけだろ。JavaScriptからやれ。
TypeScriptはJavaScriptのスーパーセットだからJavaScriptは使えなければならない。

どっちやねん

大丈夫だが特にメリットがない、でFA
・JavaScriptの方が環境的な意味で遥かに学習しやすい
・JavaScriptから始めてTypeScriptに乗り換えても学んだことは厳密に100%活かせる

>>390
なるほ、資料少ないのは辛いな。じゃばすく覚えてからにするよサンクス

クラスやモジュールのような覚えなくても済むノウハウは結構あるから
さらっとJavaScript入門を流したらあとはTypeScriptでいいと思う

これ自体をやる必要があまりない。
東京人が地方の方言を真似するようなもの。内容は違わない。

ES6もあるし、やる必要ないなんてことは無いでしょ
コレ一本で行くってんなら別だろうけど

同じ事考えてたんだけど
やっぱりやるんならjavascriptからなのか・・・

やっと分かったJSのthis、みたいなブログの記事よく見るけど、もう頑張ってJSやらんでもTypeScriptでいいだろ。

いいだろうとかじゃなく
Javascriptなら基本から学ぶ教材がその辺にあるけど
TypeScriptの奴ってどこもJavascriptがわかってる事が前提の奴だよね
知らない人が学ぶのは不可能

JSがどうにもバッドノウハウだらけの言語だから、それを隠蔽すべくTypeScriptはじめ多数のベターJSがある。
バッドノウハウでも覚えた方がいいって考えもあるだろうけど、そんな暇あるなら別の勉強した方が良いと思う。

JavaScriptを最初の言語にするのには賛成しかねる
ほんとに最初ならJavaかC#あたりなんじゃない

JQueryとかで数行書いてるだけだったら別に要らないんだよ。

Javascriptでライブラリを書き始めたらありがたみもわかる。

Javascriptでライブラリを書く土方なんて居らんだろ
使い切りのクレクレ厨ならTypeScriptなんて不要

今日の釣堀
http://itpro.nikkeibp.co.jp/article/Watcher/20130331/467401/

知らない事を知らないと言えるのは大事だな

<reference path=" で探しに行くディレクトリを追加する方法はありますか?
../../lib/hogeとかあんまりやりたくないので

>>404
インポート用のファイルを用意してそれを参照するか、コンパイルオプションで対応するしかないね
当然後者ではIntelliSenseが効かない

まだまだ駆け出しだから足りないものは多いよ

0.9.0アルファ版を少し触った感想

BOM付きUTF-8では日本語が使えない。BOMなしUTF-8はOK、SJISはNG
Type[]はまだ使える。Arrayを拡張したい場合はinterface Array<T> { ...じゃないと駄目
構文チェックが厳格になった

関数のシグニチャ、レシーバー（コンテキスト？）の型を規定することはできんのね
あとScalaのtraitみたいのがほしいなー。多重継承でもいいからお願いしますMS様

目標はES6

boolでいいじゃん
booleanとかいちいち打つのだるいわ

ないなら作れよ

0.9.0のソース上がってるな

Announcing TypeScript 0.9
http://blogs.msdn.com/b/typescript/archive/2013/06/18/announcing-typescript-0-9.aspx

TypeScript 0.9について語るAnders Hejlsbergらの動画
http://channel9.msdn.com/Blogs/Charles/Anders-Hejlsberg-Steve-Lucco-and-Luke-Hoban-Inside-TypeScript-09

ジェネリクスは大きいな

有名どころのライブラリ*.d.tsを大量配布してるサイトとかない？

https://github.com/Diullei/tsd
https://github.com/borisyankov/DefinitelyTyped

こんなのあるよ

まじか。これはGJというほかないわ

テストはcoffeeでやろうかなあ
あんまり言語混ぜ混ぜもどうかと思うがtsでテスト書くのはちょっとだるい

>>416
ありがと、助かるわー

http://www.infoq.com/jp/news/2013/06/funscript
http://funscript.info

js を typescript の type providers で wrap して
その上に構築されたF#風言語らしいが…関数型言語好きやね

Collection<Collection<...>> みたいな型表現をしようとすると
A generic type may not reference itself with a wrapped form of its own type parameters.
というエラーがでる・・・何でこんな制限あるんですかね・・・実装の都合？

前戯前に挿入するなってことじゃね？

Announcing 0.9.1
http://blogs.msdn.com/b/typescript/archive/2013/08/06/announcing-0-9-1.aspx

超高速レビュー: TypeScript 0.9.1
http://teppeis.hatenablog.com/entry/typescript-0.9.1

入れ子型もいけるようになってたお

遅報だが

Announcing TypeScript 0.9.1.1
http://blogs.msdn.com/b/typescript/archive/2013/08/21/announcing-typescript-0-9-1-1.aspx

TypeScript 0.9.1.1 リリース 〜 v.0.9 からは待望の Generics がサポートに
http://blogs.msdn.com/b/chack/archive/2013/08/22/typescript-0.9.1.1-has-been-released-visual-studio-japanese-support.aspx

TypeScript 1.0 リリース間近 !? 〜 Web Essentials 3.0 における TypeScript サポート削除について
http://blogs.msdn.com/b/chack/archive/2013/08/27/typescript-support-on-visual-studio-and-web-essentials.aspx

TypeScriptを始めたんで、スレを頭から見てるけど
>>129の下の関数は、
function g() : number { return ((x: number, y: any): number => x + y)(1, "2"); }
って書いてるのと同じ事だから、エラーにならずに12(number)っていう戻り値になるのは
問題無いよね。
教訓としては、型指定はどんな場所でも省略するなって事だね。
alias tsc='tsc --noImplicitAny'
ってすべきだ。

型チェックできないのはその理屈でいいけど動いてしまうのが問題だって話でしょ
いくら型指定するようにしていても、どうしても型なしで扱わざるを得ない部分は完全に無くなりはしない
結論としては、実行時に型チェックをするオプションが欲しい、でFA

assert(typeof a == "number");
とかを自分で書けばいいんじゃないかね。

Haskellあたりを見習って
もっと真面目に型推論をすれば解決

JavaScriptのコードが通らなくなるからムリ

>>426
> エラーにならずに12(number)っていう戻り値になるのは

でも実際は "12"(string) になるけどね

え、なにそれウンコじゃん
やっぱCoffeeScriptにしとくわ

まさに本末転倒w

>>431
function g() : number
なのに"12"(string)になるわけねーだろ！
コード書いて試してみれば一目瞭然。

JSは文字列と数を足した結果は文字列だし
TypeScriptは勝手にキャストしたりしないから
当然gの戻り値は文字列だよ
typeofで調べてみれば？

function g() : number { return ((x,y) => x + y)(1, "Hello World"); }
の戻り値は "1Hello World"

問題解決するためのイディオムでも考えたほうが建設的

解決策：あてにならない形注釈は捨てて
簡潔なコードを書くためにCoffeeScriptを使う

ただでさえJSerの無能率は高いのに
ドカタが好むエッセンスを振りかけたTypeScriptに
純度の高いバカが集まるのは必然だな

Coffee読みづらいわ
RubyやScalaを意識してるんだろうけど、あの手の省略大好き言語の中でも
ずば抜けてセンス悪い

ただでさえ意味不明になりがちなRuby/Scala系のスタイルに
さらにインデント記法を混ぜたのが大失敗
TypeScriptくらいかっちりしたのをそのままインデント記法にするか、
Ruby/Scalaみたいに他省略しまくりでもbegin/endだけは省略しないのが省略の限度だよ

具体的なコードで欠点を指摘できないと
単なる決めつけで終わってしまうね

変数の型と違う型の値が
簡単に入ってしまうのは地雷すぎる

これに比べれば大抵のことは許せる

うぐ…stringだた。
function g() : number { return ((x: number, y: any): number => x + y)(1, "2"); }
document.body.innerHTML = g();
で、
greeter.ts(13,1): error TS2011: Cannot convert 'number' to 'string'.
ていうエラーが出るからnumberだと思っとった。(document.body.innerHTML = String(g());はOK)

実際にtsc --noImplicitAnyで静的型チェックが通っても、anyが紛れてると信用ならなくなるって事だな。
こわいこわい。

tsc --noImplicitAnyしたあとanyでgrep(検索)までしないと駄目なのか…

>>435へのアンカーを忘れた

んなこと言い出したら既存JSライブラリに対する型宣言なんか全部当てにならんぞ
型が後付けである以上仕方のないことだし、それ故のメリットもある

ECMAScriptも7になれば静的型チェックは入るんだよな。
ただ、7がリリースされるのは2017とかだろうから、それまでにTypeScriptが駆逐する
可能性はある。IEがネイティブサポートしたら、その可能性は高まる。

静的型チェックで地雷とか、JavaScriptに何を求めてるんだろ

太いうんこ出た
きもちECMA

emscriptenやgwtやjs_of_ocamlのようなのだろ。

いや全然違うだろ
基本的にJavaScriptを中間コードとして扱わず、ほとんど型チェックを行うだけ
どっちかというとjshintの類だ

最新Windows用になったIEのネイティブサポートとかもう大局に影響しないだろ

TypeScriptはザックリ言うと、ES6に静的型チェックと(それ故に必要な)Genericsを追加したものだな。
良い言語だと思うけどね。

TypeScript、Haxe、Dartの三択だったらどれ？
CoffeeScriptはもうやってるんだけど、新しいのを覚えたい。

方向性がそれぞれ違うから用途と目的によるとしか。
ざっとググってみてもピンと来ないならTypeScriptでいいんじゃね

JavaScriptが大嫌いで無茶苦茶に汚してやりたいって人にはDart
監禁されて二人だけの世界で言いなりにされたいって人にはHaxe
どちらにも当てはまらない人にはTypeScript

JavaScriptは一斉排除だ！って環境ならなんでもいいよね
親和性を取るならTypeScriptは書きやすい

TypeScriptはVisualStudioで開発したら世界が変わるで。

記述ミスをビルド前に指摘してくれるのはうれしい。

VisualStudioでプロジェクト作らずに直接TSファイル開くと
依存関係から仮想プロジェクト機能が働くんだけど、これが便利すぎる

ざけんなよMac無視かよ

>460
WebStormがあるじゃないか！

盛り上がってるね。

JavaScriptが超好き！覇権言語！ → JavaScript

なんだかんだでJavaScriptの未来を信じてる。でも型チェックは欲しいお……
Visual Studio大好き！ → TypeScript

「JavaScriptで大規模アプリを作るのはジョークだ」（言語設計者談）
つかブラウザ自体単なるコンパイルターゲットのひとつとしか見なしてない
なぜECMAScript4を捨てた。バカじゃねーの
関数型言語大好き！ → Haxe

「JavaScriptは問題を抱えている」
JavaScriptなどいずれ滅ぼしてやる → Dart

C++サイコー！実用的な言語！ → Emscripten

こんな感じ

TypeScriptかHaxeかというのがよく話題になるが、
ぶっちゃけJavaScriptが好きか嫌いかで選べば間違いないｗ

あとは我が道を行く闇のC++軍団。
なんだかんだで最終的にガチC++erはウェブでも一定勢力を占めそうだ。

JSXのことを完全に忘れていたのだがどうなったのだろう

クラスを定義するために宣言ファイルと定義ファイルを用意するとして
この定義ファイルから同宣言ファイルを参照すると面倒が起きやすい点がなんとかなればな
(一応大体の事は対応できるけども)

JSXはコンパイル後の出力が汚いだろ

Emscriptenでどの程度まで出来るのか今一分からんな。
DOMをいじれるのかとか

TypeScriptの => を使っても、結局イベントハンドラとかのthisのややこしさは
カバーしきれない感じなんだけど、Haxeはもっと上手くごまかしてるの？

>>467
https://github.com/kripken/emscripten/tree/master/system/include
ヘッダー眺めればざっくりとは分かる

test

test

>>468
haxeは、クロージャの中でもレシーバー(this)は変更されない。
なので、jQuery.map()等で、クロージャでDOM要素に直接触る場合は、第二引数まで指定して受け取る必要がある。

これを面倒と取るか、シンプルさで混乱を避けているとるかは人それぞれ。

こじんてきにこのきょどうにふまんはないです。

0.9.5リリース上げ！
動作の安定化とビルド時間の短縮が主な変更点かな。

定数オーバーロードはstringしか出来ないのか。他のプリミティブも出来たらちょっと楽しそうなのに。
interface I{
　f(x:"A"):Alice;//可
　f(x:string):Person;
　g(x:2):Alice;//不可
　g(x:number):Person;
　h(x:true):Alice;//不可
　h(x:boolean):Person;
}

今年は1.0くるかね

試しにTypeScriptでMongoDBのクエリを解釈するサンプルを作ってみた。
https://github.com/kanryu/puremongo

$where でfunctionを直接クエリとして渡す部分があって
そのcallbackのthisは検索中のdocになるから
JavaScriptやTypeScriptだと問題ないけど
Haxeだと面倒なのかな？（よう知らん）

class QuerySelectorで様々なoperatorをobjectにぶち込んで
operators["$where"](...) などの形で呼び出せるように工夫してみたけど、
staticメソッドだとうまく記述できなかったので通常のメソッドにせざるを得なかった。

お陰でvar self = this; なんて回避コードがときどき必要になるね。

TypeScriptとES6の関係がわからない。
ES6が普及したら いらない子になっちゃうの？
誰か背中を押してくれ

ES6なんてまだ現実的な話じゃないけど、そこで悩むくらいならC++かDartあたり選ぶんじゃないか

http://typescript.codeplex.com/wikipage?title=Roadmap
http://teppeis.hatenablog.com/entry/typescript-webdbpress75

あまり調べてないがTSレベルの静的型付けはES6になさそうだから、
IDE支援使う分にはTSの方が便利のままなんじゃないかと。

ES6に変換出来るようにするみたいだし、潰しは効くんじゃないか。

>>479
なるほどー

なんか NodeBufferの型が存在しないって Windowsでだけワーニングが出るけどこれどうしたらいいん？
Unix上では問題ないみたい。

E:/Home/src/typescript/pmx/node.d.ts (98,9): Expected ';'
E:/Home/src/typescript/pmx/pmx.ts(26,17): The name 'Buffer' does not exist in the current scope
E:/Home/src/typescript/pmx/pmx.ts(35,17): The name 'NodeBuffer' does not exist in the current scope
E:/Home/src/typescript/pmx/pmx.ts(44,17): The name 'NodeBuffer' does not exist in the current scope
E:/Home/src/typescript/pmx/pmx.ts(53,17): The name 'NodeBuffer' does not exist in the current scope
(以下略)

最新のnode.d.tsをカレントに置いて
///<reference path="./node.d.ts" />
してある。

-dオプションで.d.tsファイルが作れるのはすごく便利なんだけど
参照ファイルも全部記述してくれるせいで.d.ts側には必要ないものまで参照しちゃうな

その.ts内だけで使える/// <reference同等の参照があればいいんだけどな
複数ファイルをまとめてコンパイルした時に他のファイルには影響が出ないようならなお良い

上のエラーだが、とんでもない原因だった。

nodejs本体はときどき入れ替えて最新のを使ってるんだが、
VisualStudio用のnodejsが古いままで、PATHに含まれてたのが原因で誤動作してた。

これは気づかんで……。

馬鹿には無理

> Initial commit of TypeScript 1.0 made to codeplex on Feb 20.
> Branched as release-1.0 too. Hoping RTM is next week.

うおおおはやく発展しろおおおおお
みんな使おうぜええええええ
Coffee構文に対応したコンパイラとか出てこないかな
もはや別言語か

0.9.5が出てからぱったり更新が止まったな

0.9.7についてのドキュメントが出てきてる。

http://blogs.msdn.com/b/somasegar/archive/2014/02/25/visual-studio-2013-update-2-ctp2.aspx
TypeScript 1.0 RCが出たよ。

あと、
> We are also now adding TypeScript support into the Visual Studio 2013 product, starting with Update 2.

おおー　きたー

コンストラクタを見せかけだけでいいから非公開にしたいんだけど
private constructorがコンパイルエラーなのがつらい
面倒になるから出来る限り宣言ソースは直に触れたくないんだよなぁ

>>491
それは仕様バグなのか何らかのポリシーなのかわからんね。

JavaScriptの仕様上コンストラクタの隠蔽だけは実現不可能だからだろうね
今のところ非公開要素のコンパイル後のコードはオープンな状態だし、許容してくれるようになればいいんだけど

>>489
何が変わるんでしょ
なんだかんだ言いながら0.9.5で使えてるわ

1.0RC関連
ttp://blogs.msdn.com/b/typescript/archive/2014/02/25/announcing-typescript-1-0rc.aspx
ttp://www.forest.impress.co.jp/docs/news/20140227_637313.html

出力コードの最適化は来ないのかな
言語レベルの定数とかインライン展開でClosureコンパイラで手がまわらない所まで最適化したい

たぶん出力jsの可読性考えてやってないんじゃない？
jsxとかあるから技術的には可能だと思うし

>>496
mixinとかってこと？

Eclipseのプラグイン使ってみたけど
VisualStudioに比べてインテリセンスが死ぬこともないしアウトラインも機能してる
エディターの色分けがまだ変えられないのと、宣言ファイルもソースフォルダの中に無いといけないのがちょっと不便
ファイル関係のことはリンクでカバーできるからまだ良し

vs2013 + 1.0RCでプロジェクト作っていくつかTSファイル用意するとIntelliSenseもコード補完も効かなくなる
試しにプロジェクト作らずにそれらのTSファイル全部開いて、仮想プロジェクト上でやったら問題無いとかどういうことなん
プロジェクト作っちゃいかんのか

>>500
システム中にnodejsが複数バージョンあると競合することがあるから注意な。

TypeScript 1.0がリリースされた件について
http://blogs.msdn.com/b/typescript/archive/2014/04/03/announcing-typescript-1-0.aspx

うほっ

>>224
なせま、すばらしい言語は作れるのに、すばらしいOSが作れないのか？

OSは、したばたらき。えんのしたのちからもち

きたかー

感慨深いです。

Microsoft、プログラミング言語“TypeScript”を正式リリース
ttp://www.forest.impress.co.jp/docs/news/20140403_642703.html

“TypeScript”は、“JavaScript”へ静的型付け、クラス、モジュールといった機能を追加し、
多くのコンポーネントから成る大規模アプリケーションの開発に耐えうるものへ拡張

TypeScriptでRequirejs使うのって何を意図してんの？
外部モジュールやreference path じゃ不都合の出るケースがあるの？

全てTypeScriptで成り立つなら使う必要はないかもしれないけど
参照以外はJavaScriptが相手だしな

Arrayのconcatに値と配列を一緒に渡せるようにするのは今の仕様じゃ無理か
concat(...items: T or Array<T>)
みたいなややこしいもの実装するくらいならコード見直すなりキャストするなりした方がいいな

アクセサのget と setあるじゃん
これらのアクセサでインターフェイス作りたいときはどう書けばいいのでしょうか？
詳しい方教えてださい

interface Person{
get name() : string;
set name(value : string);
}

のようなかんじなんでしょうか？

.d.ts吐かせてみたらname: string;になったよ
使う側にしてみれば確かにそうだよな

>>513

interface Person {
name: string;
}

class MyPerson implements Person {
public get name(): string { ... }
public set name(value: string) { ... }
}

yieldやawaitが早くほしい

Swiftスレ
http://peace.2ch.net/test/read.cgi/tech/1401736341/

promiseほしい

アナフォリックマクロがほしい

穴堀っく？

TypeScriptあるある
.tsをいじってると思ったら.jsの方を直していた…

俺はVS使ってないからかなぁ

class使ってるとネストの深さで気付くけどnode.jsならあるある

Visual Studio 2013 update2で編集してると、たまに自動インデントがずれない？
メソッドチェインが複数続く中にクロージャが入るようなパターンで。

Grunt使って *.d.ts を自動管理するようにプロジェクトを構築してみた。
こうしないとJavaScriptの外部ライブラリを使うTypeScriptのプログラムがろくに書けない。

このへんめんどくさいよね。

>>524
自動管理って具体的にどういうこと？教えてもらえると助かる

tsd

>>512
コールシグニチャ使って、関数オーバーロードすれば？

>>526
なるほど、まぁでもtsdはそんな頻繁に使うもんでもないし…

>>528
拾ってきた*.d.tsをそのままソースツリーに入れてると、それが古くなったときに困るから
Gruntで最新の定義ファイルをセットアップできるようにしてある。
githubに置いてあるからよかったらどうぞ

>>529
おぅ、Grunt使ってないから使う時が来たら参考にさせてもらうよ

Microsoft自体はTypeScriptで何作ってんだろ？

困った…
...
getElementsByTagName(name: "title"): NodeListOf<HTMLTitleElement>;
getElementsByTagName(name: string): NodeList;
...
ってオーバーロードされてて、たまたま'title'を渡してコールしないといけないけど、
戻り値の型がHTMLTitleElementになってコンパイルが通らん…

強制的に(name: string)の方をコールするにはどうすればいいでしょうか？

<NodeList>getElementsByTagName("title")
としたくないのであれば
getElementsByTagName(<string>"title")
とか
var name = "title";
getElementsByTagName(name)

>>533
> getElementsByTagName(<string>"title")
これでうまくいった！
最初これで試した気がしたけど思い込みだったか…
ともかく助かったありがとう！

しかし、文字列リテラルでオーバーロードできるってなかなか面白い言語だな
さすがヘルスバーグが関わっただけあって実用性第一なとこがいい

まあもともと何でも通すJavaScriptだからな

合計15000行程度のJavaScriptをTypeScriptへ移行させて思ったこと

.jsを見るとコメント行の直後の空行が削除されてる…なんでや
tscに.jsのインデントを空白2にするオプション付けてくれ(代替コマンドを使えば出来るらしいが)
typoで存在しないメンバーにアクセスしてifが常にfalseになっていた超分かり難いバグを修正できた！

全般的に色んな型を意識することでプログラムが正しく動いてるっぽい自信は付いた
苦労した甲斐はあった
後悔はしていない

lib.d.ts とかで↓の書き方を見るけど

interface Hoge {
...
}
declare var Hoge: {
prototype: Hoge;
new (): Hoge;
}

なんで interface と var の二段構えにするのか分からん…
理由を教えてください

最初は継承(extends)を抑制するくらいかなぁと思ったけど
その例に出てるように、体面上prototypeを通してインターフェースのメンバーにアクセスできるのは大きいんじゃないかね

何か足りてない気がしたので補足すると
class Hogeだった場合、Hoge.prototypeはany型なので

前は依存関係で難しかった全ソースを1ファイルから参照してコンパイルが
参照する順番とか気にせずできるようになってるな
project.tsにプロジェクト内のソースと.d.tsの参照をまとめて突っ込んで
これにtypescript-toolsのTSS使うとお気に入りのエディタだけで完結できて捗るな

>>537
例えばErrorオブジェクトだと↓のような定義だけど
interface Error {
name: string;
message: string;
}
declare var Error: {
new (message?: string): Error;
(message?: string): Error;
prototype: Error;
}

色々調べたところ、こう書かないと同じにならないからだった
classで普通にオブジェクトを作ると↑のようにはならないけど、
既存のJSオブジェクトは若干イレギュラーな宣言が必要になるようだ

しかし良く考えられてるわ
JSのヘンテコな継承システムをちゃんと定義出来てるんだもんな

JSの代替言語としてはTypeScriptが唯一と言える
ここまでやらないと代替言語とは言えない

動的型向けの妙な使い方ではmoduleを使ったマージなんてのもある
function Foo() {}
module Foo { export var Bar = 0; }
関数とか既に存在するオブジェクトにプロパティを持たせるのに使える。しかもコード補完も有効

declare class IGreeter {
static greeting: number;
}
class Greeter implements IGreeter {
static greeting: string;
}

これで通るのが意味わからん

>>542
マージもそうだが、構造的部分型とかもJSに溶け込む為には必要な言語仕様だな

>>543
インターフェースとdeclareは実体が存在しないからstaticな変数は存在する余地がない
だからIGreeter.greetingは無いことになってるな

class Greeter implements IGreeter {
↓
class Greeter extends IGreeter {
にすると正しくエラーにはなる
implementsはインターフェースとして扱うからか？

>>544
thx
インターフェースはstatic書けないのにアンビエントは書けるから使えるかと思ったら書けるだけで無視されるのか
間違いの元だから構文でエラー出してほしかった

>>544
現状の declare class + implements でエラーにならないのは何か理由があるのかね
単なる仕様の抜けな気もするけど

operator overload が実装されて欲しかったけど、公式のフォーラム見たかぎりだと完全に無理っぽい
やっぱりJavaScriptとの親和性を考えると難しいかな

イベントターゲットの型がHTML要素と互換性ないのはいいのかこれ

function test(obj: HTMLElement){}
var button = document.createElement('button');
button.textContent = "Say Hello";
button.onclick = function(event) {
test(event.target);
}

document.body.appendChild(button);

ああ、<HTMLElement>event.targetでアサーションかますのか

>>549
その辺の元からあるやつは型調べないと全然わからんわ

>>550
W3CのDOMの仕様に書いてあるIDLとか見るとちゃんと忠実に型付けされてるが、
そもそもの仕様がスゲー複雑という問題が…

素のJavaScriptの時はメンバーの有無だけ分かればよかったからお気楽だった

declare class と interface の使い分けが今一分からん

interface Point {
x: number;
y: number;
}

declare class Point {
x: number;
y: number;
}

どっちでも同じ結果になるし…

コンストラクタの型指定とか

declare class i {
constructor(m: any)
}
class Greeter implements i {
constructor(m: any) { }
}

extendsできるものを.d.tsに書くことができるってくらいじゃないか
メンバーの公開が目的ならインターフェースのほうが適任だと思うし、そんな深く考えなくてもいいんじゃないの

コンパイラの-dオプションもたまには思い出してあげて下さい

そーいやコンパイラのオプション全然知らずに使ってるｗ
ES5とcommonjsつけてるだけだ

全体を無名関数で包む方法がないのはなんでだ

JavaScriptのスーパーセットということを考えると妥当だと思うが
無名moduleで囲むんだ

まあJavaScriptでできないから妥当ちゃ妥当か
Coffeeみたいにコンパイルしたあと全体をラップしたかった

返答遅くなった
>>553,554
ご意見どうも
コンストラクタの型指定以外はinterfaceでよさそうだ

>>557
moduleには名前を付けないとエラーになるけど、無名moduleって出来るの？

これオーバーロードの引数にオブジェクト型使うと型チェックされなくなるじゃん
ひっでえ罠

だってみんなオブジェクトだもの

だからInterface

>>560
TypeScriptにオーバーロードはあるけど、結局は実行時にinstanceofとかで判定するだけだからね
あえて余計な拡張をしないってところが最高だが

出力されるJavaScriptがゴリ押しなんだよなｗ

>>564
書いたコードが大体そのまま出てるわけだから、別にゴリ押しでも何でもないと思うが

>>564
むしろTypeScriptが吐き出すJavaScriptは標準的で綺麗だと評判だぞ。

機能追加要望にabstract classがあがってるけど、それにプラスして
C#みたいにvirtual, overrideの指定が出来るようにしてほしい

virtual, overrideが追加されてもJavaScriptの互換性は壊さないはず(単に消えるだけ)

むしろ非virtualのほうが無理じゃね？

>>568
ん？どういうこと？
class Base {
hage(): void {

class Derive extends Base {
hoge(): void { ← オーバーライドしたつもりが間違ってる…エラーにもならない

var base = new Derive()
base.hage(); ← 気付き難いバグ

C#はvirtual, overrideのキーワードが必須で噛み合ってないとコンパイルエラーになる

JavaScript的に同名プロパティはoverrideにしかならないってことだろ
エラー出してほしいなら面倒でもインターフェース用意するしかないね、今のとこ

>>570
なるほど、そういうことか
確かにC#だと同名プロパティをoverrideにしなくは出来るね

virtual, overrideが追加されればいいけど、abstract classとprotectedは
今後追加されるっぽいし、もうほぼC#といってもいいな
こりゃ最高だわ

TypeScriptにはawaitパターンの実装を期待する。
たとえnodejs専用になってもいい。

awaitはロードマップには書いてあるから実装されるはず
JavaScriptの方でもES7でawaitが入るらしいから、また先取りな感じの実装になりそう
ES6だとyieldでエミュレートできるだろうけど、ES5でも動くようにするには
相当ソースを変形して出力しないと無理そうだから、awaitはES6以上必須になる気がする

改めてロードマップ見たらawaitはハナからES6がターゲットだった
ES6が当たり前のように使えるようになるまでawaitは使えないね
いつになるのか分からんが…

traceurじゃyieldとか実装してるんだしやろうと思えば出来るだろ
むしろtraceurを全部取り込んでくれ

TypeScriptは綺麗なJavaScriptの出力が重要視されてる
awaitをES5で出すには大幅なソースの変形が必要だから絶対やらないよ

ちなみにどんだけ変形が必要かは↓ここみると良くわかる
http://kyle.graehl.org/es6/javascript/development/2013/08/27/use-es6-yielding-today.html

MozillaのFlash代替プロジェクトのShumwayでTypeScriptが普通に使われてた
Mozillaすら使うようになったとはすばらしい

ほぉ

これからtypescriptを覚えようと思ったけどdartが標準化されたから消えそうだな

ECMAの件は確実に勢力図塗り替えるねー

TypeScript、悪くはないと思うんだが決め手が足りん

JSのある意味一番肝心なthis回りのgdgdがそのままだし、
コンパイラ遅いし、なんだかんだでロックインされそうな気がするし、
CS、Haxe、DartとAltJS全部に言えることだが、総合的に得してるのか損してるのかよく解らん

オレしばらくJavaとかSwiftとかC#（Unity）とかやってるからES7が来たら起こして

>>581
Dartと違って文法がスーパーセットなのが移行を楽にしたんだけどね
でもDartも馴染みやすい文法してるから慣れるのは早いかな

Coffeeはダメだ今となっては誰得

まず前提としてJavaScript自体に人気があるし、業務で使うにはJavaScriptと
親和性が高くてデバッグに支障が出ないもの(重要)を選ばざるを得ないから
必然的にTypeScriptを選択する事案は増えるだろう

>>581
this周りのdgdgは解決されてるし、コンパイラは--watchしておけば裏で自動的に
コンパイルして大体1〜2秒で終わる
最終的に綺麗なJavaScriptを出力する事が目的なのに、ロックインとかも意味が分からん…

ネットには実際大して使ってない奴の適当な批評だらけだが、これはマジでいい言語
まぁC#の方がいいとは思うが、それにかなり近い(近付いてる)とは思う

MSの言語はお行儀がいいからな
面白みはなくても無難にしっかり使えるというか
Googleはその辺信用ならん

10ファイル各200行程度に分割したソースをコンパイルすると3〜5秒くらいかかる
このくらい2秒以下で終わるようにしてくれ

>>585
それは--watchしての時間？
36ファイル(jquery.d.ts等含む)でそれぞれ平均400行以上あって--watchだと2秒かからん
CPUは4コア8スレッドで3.4GHz

>>584
地味な言語だけどVSで開発出来るあたりが地に足が付いてる感がある
開発はほとんどPCでやるわけで、PC用OSを持ってないGoogleには越えられない壁がある

>>586
そういえばwatchはコンパイラじゃなくてGruntでやってたからコンパイラにやらせて計ってみる
CPU2コア2スレ2.9GHｚメモリ8GB

watchオプションで監視したら1秒になったthx

すまんやっぱだめだ
watchだと変更されたファイルだけコンパイルされて変更のないファイルが抜ける
テストは結合する前にやれということかこれは

>>590
そりゃそうだろ…
変更してないのに再度コンパイルする必要ないし
///<reference path='hoge.ts' />
しておけば、hoge.tsは無変更でも一緒に必ずコンパイルはされるが
そういう事じゃないんだろうね

>>591は間違えた…
俺は全.tsを1コマンドに渡してるけど.jsの日付は毎回全部更新されてた

>>591
依存関係は親は書けても子は書けないから親の変更だと子抜きで出力されるよね？
親クラスと子クラスを別ファイルに書いて1つのファイルに出力したいときに親だけ変更すると子抜きで親だけが出力されてしまうといった具合

>>593
普段は結合せずに全jsをロードするようにしてるから言わんとしてる事が分からんかった
そもそも個別にロードしないとデバッグがむずい

とりあえず手元で試したところ全く依存関係のないファイルも常に1ファイル内に出力されたよ

tsc --out out.js --watch hoge1.ts hoge2.ts .... hoge30.ts
って全部渡してる？

tscじゃなくてgrunt-typescriptのsrcとwatchオプションでやってる
tscでも試したかったけどなんでか--watchがなくてできなかった
Windowsなのがいかんのか…

Version 1.0.1.0
Syntax: tsc [options] [file ..]

Examples: tsc hello.ts
tsc --out foo.js foo.ts
tsc @args.txt

Options:
--codepage NUMBER Specify the codepage to use when opening sourcefiles.
-d, --declaration Generates corresponding .d.ts file.
-h, --help Print this message.
--mapRoot LOCATION Specifies the location where debugger should locate map files instead of generated locations.
-m KIND, --module KIND Specify module code generation: 'commonjs' or 'amd'
--noImplicitAny Warn on expressions and declarations with an implied 'any' type.
--out FILE Concatenate and emit output to single file.
--outDir DIRECTORY Redirect output structure to the directory.
--removeComments Do not emit comments to output.
--sourcemap Generates corresponding .map file.
--sourceRoot LOCATION Specifies the location where debugger should locate TypeScript files instead of source locations.
-t VERSION, --target VERSION Specify ECMAScript target version: 'ES3' (default), or 'ES5'
-v, --version Print the compiler's version: 1.0.1.0
@<file> Insert command line options and files from a file.

テスト鯖のLinuxにインストールしたら--watchあるので窓環かな、窓だとinotify使えないし
grunt-typescriptのwatchはtscに流してるのかと思ってたけどソース見たら独自実装ぽいので
ソース指定無視するのはtypescriptじゃなくてgrunt-typescriptの問題ぽいです
お騒がせしました

>>596
Windows7だが普通に--watch使えてるよ
しかし>>595を見るとなぜか--watchがないw 何でだ？バージョンも一緒なのに
多分typescriptを単体で入れてないで、何らかの依存関係で入った独自版の気がする

inotifyそのものは無いけど、Windowsにも同じ機能はだいぶ前からあるよ

>>597
Winで--watch使えると知れたのは救われます
もっかいインストールしなおして調べてみます

解決
VisualStudio同梱のTypeScriptの使用を強制されてnpmで入れたのを使えなかったのが原因
C:\Program Files (x86)\Microsoft SDKs\TypeScriptフォルダをエスケープして使えなくしてnpmでグローバルにTypeScript入れれば

Version 1.0.1.0
Syntax: tsc [options] [file ..]

Examples: tsc hello.ts
tsc --out foo.js foo.ts
tsc @args.txt

Options:
-d, --declaration Generates corresponding .d.ts file.
-h, --help Print this message.
--mapRoot LOCATION Specifies the location where debugger should locate map files instead of generated locations.
-m KIND, --module KIND Specify module code generation: 'commonjs' or 'amd'
--noImplicitAny Warn on expressions and declarations with an implied 'any' type.
--out FILE Concatenate and emit output to single file.
--outDir DIRECTORY Redirect output structure to the directory.
--removeComments Do not emit comments to output.
--sourcemap Generates corresponding .map file.
--sourceRoot LOCATION Specifies the location where debugger should locate TypeScript files instead of source locations.
-t VERSION, --target VERSION Specify ECMAScript target version: 'ES3' (default), or 'ES5'
-v, --version Print the compiler's version: 1.0.1.0
-w, --watch Watch input files.
@<file> Insert command line options and files from a file.

--watchが使えるようになりました
VisualStudioもエディタとして使ってる分には挙動の差異なし
以上参考までに

protected, await対応するってよ
ttp://www.slideshare.net/chack411/typescript-10

>>600
その辺は1.0出る前からロードマップには入ってたよ
https://typescript.codeplex.com/wikipage?title=Roadmap

>>601
この対応ってES6出力限定？

> （ES6 の糖衣構文展開）

糖衣構文展開という用語がよくわからなかったけど>>576のように使わせてくれるわけではないのな

>>576はawaitが裏でどういう動作をしているか勉強にはなるが、await1つ書いただけで
こんなに展開されたら邪魔過ぎるよ

>>605
TypeScriptの原型の一つとも言えるC#で
実際そんなコンパイルがされるから何も不思議ではない。

>>606
別に不思議だとは言ってない
大量の余計なコードでデバッグがしづらくなりそうだという事

MSILを見ずにデバッグできるのが当たり前なC#
JavaScript変換後のソースを見ることを考慮し、綺麗なソース出力を特徴とするTypeScript

この2つを同じように考えるのは俺もどうかと思うね

601を今読んだけど、
TypeScript 2.0に向けた新機能の一環で、
同時にECMAScript 6 outputに対応するようだから
それほど複雑なことにはならないんじゃないだろうか。

yieldとかもそういう（限定的な）対応だし。

ソースマップがすべて解決してくれるさ(適当)

>>609
awaitはES6のyield使ったコードが出力されるからシンプルなはず
ES6のclassとか先取りしたみたいに、ES7で実装される予定のawaitが実装されるみたいだ
http://wiki.ecmascript.org/doku.php?id=strawman:async_functions
↑ここ見るとawaitとyieldの対応がなんとなく分かる

1.1からコンパイラが速くなるってよ

平行して一から作り直してるのがあったんだな。で、5倍も速くなってると
もうちょい時間掛かりそうだけどこれは期待できる
TypeScriptチームは有能

今ほんと遅いから期待

--watchしてる？
40ファイル弱15000行あっても1〜2秒だぞ

しかもホスティングサイトも自社のCodePlexからGithubへ移行しちゃったよw
CodePlexのUIが糞だったかららしいが、随分思い切った事するもんだ

Github自体はクローズドだから、これに依存し過ぎるのもどうかとは思うが

>>616
表向きの説明は、フィードバックをたくさんの開発者から受けるためになってるがｗ

リポジトリ自体は単なるGitだし、Wikiとかは独自に持てばいいし、Github依存なのはIssueの管理ぐらいだと思うけど、
でもいきなりIssueが150件とかあるね？日付見る限りこれはCodePlexで管理してたのをGithubに転送できたってことだね？
これができるならGithubに縛られるわけじゃないから問題は無いと思うな

TypescriptでやるかEmscriptenでやるか
実に悩ましい

TypeScriptをC++に変換したいとは思っている

>>619
Emscriptenでやるかっていう選択肢は無いな
デバッグとか困難だから、普通のネイティブアプリを作って一通りデバッグが済んだ
ものを変換する為のもんだと思うよ

これthisの型定義はできない？

(<any>this).foo();

型情報を保持するやつを頼む

var hoge = <Hoge>this;
他の言語いじった事無いのか？

「thisの型定義」ってのがイミフ

キャストかな？

thisをthisのまま型を持たせる取り回しがしたい

thisはちゃんと型定義されてる
他の型にすると言うことはダウンキャストがしたいんだろう
>>625以外のやり方なんて無い

thisをanyから何某へのダウンキャストは常用してるけど面倒だったので。
thisのまま持って歩くこと自体やるべきじゃないということか。

>>626
node.jsだとクロージャ内のthisを多用するようなライブラリあるから、
thisが自身のクラスとは限らないぞ

>>631
thisが変わりうるfunction記法ならthisはanyだし、thisが変わらないアロー記法ならthisは型付きだけど、それが何か？
安価の行方もイミフ

>>630
ダウンキャストしたら変数名は変えるべきだ
(変える以外無いが)
つうかダウンキャストしないで済む方法も色々あるよ

なんだ新人研修か

どうせまともに分かってるやつ居ない

>>635
お前よりは間違いなく分かってるよw

そういう場合は先に型定義ファイルを用意することを考えるべきではないのか。

ｊQueryやIDBのコールバックのコンテキストの型定義するのめんどくさい

>>637
thisの型の話しなんだから型定義ファイルは関係無い
>>632が言ってるように単なるfunction内のthisはany、アロー記法とclassのメソッド内は型付きになる
ってだけ

>>638
JavaScriptはコールバックに単なるfunctionを渡してもthisにアクセス出来るという他の言語に無い特徴がある
これは便利でもあるし、混乱の元でもある
当然単なるfunctionなんでthisの型定義は出来ないからしょうがない

過疎スレ

消えへんでー

JavaScriptってザックリ
LISPと言うのかリスト構造を便利に扱えるアセンブラみたいな感じ？
便利で自由だけど自己責任でどうぞな部分がありみたいな

>リスト構造を便利に扱えるアセンブラ
なにそれ！使ってみたい！

>>642
なぜTypeScriptスレに書いてるか知らんが、JavaScriptにはリスト構造を簡単に扱う仕組みは無い

>>643
それがLispだ
昔はLispを直接実行するハードがあった
Lispマシーンでググると色々出てくる

よく話題になってるasm.jsは、c/c++コードをマシン語代わりにasm.jsに変換して、jsのコードを型チェックとGC切った状態で実行する仕組みなので、ある意味asm.js用のjsコードがマシン語に対応してる。
http://gigazine.net/news/20130322-firefox-asmjs/

最近の進捗
https://hacks.mozilla.org/2014/05/asm-js-performance-improvements-in-the-latest-version-of-firefox-make-games-fly/

>>645
正確ではないな
LLVM IRをJavaScriptとして実行出来る形にコンバートしたものがasm.jsだ
Firefoxは実行前にコンパイルしてしまうので、ネイティブコードと同じ速度になるはずだけど、
実際には最適化が同じように出来ないせいかちょっとだけ遅くなってる

一言で言えば話のすりかえやね

EmscriptenはLLVM IR前提とするけど、asm.jsターゲットにするコンパイラはLLVMに限らないけどな

>>648
え、そうなの？
LLVM以外に何でコンパイル出来んの？
単に仕様的にってことか？

>>649
単に仕様的に。簡単な数値演算くらいなら手書き出来る。
ネイティブコード出力してるマルチターゲットコンパイラなら普通にasmjsバックエンドやれるんじゃない？

IEでTypeScriptを直接デバッグできるようになればいいのに
コンパイルしてソースマップ作るのめんどくさい

>>651
そのままデバッグしろよw
見てわかんだろ

>>651
そのままってのはJavaScriptのままって意味ね
ES6が当たり前になれば、TypeScriptのソースとJavaScriptのソースは大体一緒になる
単に型の指定が無くなるだけだ

>> 653
ES6が出てくれれば、とてもありがたいね。ES6があればTypeScriptを使わないと思う
JavaでTypeScriptを使いたいと思うけど、ちょっと相性が悪い気がする

>>654
いやいや、型指定こそが本質なんだから
ES6時代になっても全然重要度は変わらない

TypeScriptは言語というより型ヒントだよな
むしろ中途半端に記述を楽にする機能とか無くてインターフェースと型指定だけあればいいくらい

それJavaScript IntelliSenseでいいんじゃないか

TypeScriptはC++の出力はできないですか。
JavascriptよりかはC++に変換しやすそうなのに。
Javascript経由のほうがツールありそう。

JavaScriptで出来ることはany経由でほぼ出来てしまうし、結局プロトタイプベースにクラスの皮被せてるモデルのままだからC++と1体1とはいかない

てかJavaScriptの為の言語でしょ

JavaScriptを知らん人には他の言語に近く見えるのかな

JavaScriptアレルギーって結構あるからな〜

TypeScriptはJavaScriptの強制ギプスとも言える
JavaScriptは自由度が高い言語だけど、必要ない事は敢えて出来ないようにしてるところがTypeScriptの良いところ

公式のチュートリアルに出てくる数行の短いコードをコンパイルすると8年前のceleronで
real 0m13.827s
user 0m8.953s
sys 0m0.900s
このくらいでこんだけかかると何百行のコードをコンパイルするのは遅いんですが
なんですけどもっと良いパソコンだと早く終わりますか？

>>664
初回起動が遅いのはある
--watchを付けて使えば>>615だ

さらに今後リリースされる1.1だと5倍速くなる予定だ

var list:Array<number> = [1, 2, 3, "a"];
コンパイルしてもエラーにならず[1,2,3,"a"]になるんですが何故ですか？

>>666
いや、コンパイルエラーになるよ

構文さえ合ってれば多少のエラーでもJavaScript吐いてくれるからな
コンパイラのメッセージはちゃんと残るようにしないとな

やっぱり#ifみたいな条件コンパイルする機能は必要だなぁ

1.1いつでるのyo

>>670
https://github.com/Microsoft/TypeScript/milestones
ここ見ると1.1のバグは全部クローズされてるから、もうそろそろかな

protected使えるまであと何年？

>>669
cppはC以外にも使えるからとりあえずはmakeやgruntからプリプロセッサ呼べば良くない？

>>673
ソースに直接#ifって書いちゃうとプリプロセッサ無しにコンパイル出来なくなるから
書き方を工夫しないといけない

///#ifdef HOGE
...
///#endif

みたいにして、リリースビルド時にスクリプトで消すようにする

>>673-674
そこまで込み入ったことをするなら
どうせgrunt.jsなどでビルドを自動化するだろうから
無問題だと思うんだが。

まあC/C++の悪しきマクロ文化は捨て置くとして、
C#レベルのプリプロセッサ機能はあってもいいかもね。

grunt.jsって重いから使ってない
君たちどのくらいのスペックのパソコンで開発してるの？

Celeron 1.6GHz メモリ1GBの環境

そら低いやろ…10年前のスペックやぞそれ

IDE使うとlanguage serviceのnodejsだけで1G近く使ってるから少なくともメモリ4Gは欲しい

>>676
そんなゴミスペックのマシンで開発するのは恥ずかしいことだと認識したほうがいいよ
効率に無頓着ってことでしょ？

入門書読んでvisual studio express2013 for webにてtypescriptを使おうとしてるのですが、新しいプロジェクトを開いてもテンプレートにtypescript がありません。
何か設定が必要なのでしょうか？
PCはWindows8.1 64bitです
初歩的質問で恐縮です

初歩的な内容って分かってるならググったほうが早いだろ

>>680
VS2013 for WebのUpdate3（Win7 64bit）使ってるが何もしなくても出てくる
一回アンインストールして入れなおしてみろ

いつのまにか1.1出てますね

1.1のコンパイル速度
real 0m3.922s
user 0m2.404s
sys 0m0.236s

>>644のときの実行時間より1/4時間で終わるようになった

アンカミス
>>664

1.1 ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

--watchにすると37ファイル1万7千行のコンパイルが0.5秒ぐらいで終わるw
前は2秒弱程度あったから確かに4倍速くなってるかな

それに前はメッセージが何も出ないからコンパイル終わってるか分からなかったけど
メッセージも出るようになったし

ただ、出力されるjsは空行が全部詰まるようになった…
前は少しは残ってたのに完全にくっつくとか…可読性が悪くなっちゃったよ

基本的にコンパイラのリライトが目的だから、今後の拡張に向けて
大きな一歩を踏み出したと言えるし期待したい

何でそんなに早いんですか
パソコンの買い替えを検討中なのでスペックをおしえてください

>>687
いやだから、--watch使ってるからよ
$ tsc --noImplicitAny --target ES5 --outDir hoge/js *.ts
の時間はちょうど1秒だった(5回試した平均)
環境は>>586

やっぱですくとっぷのほうがいいですねわかりました

1.1はCTP(Community Technology Preview)だな
正式にリリースした訳じゃないぞ

>>690
https://github.com/Microsoft/TypeScript/releases/tag/v1.1

>>691
そりゃタグぐらい打つだろう
ただ、1.1自体がCTPという事かもしれん
互換性の問題とか細かい修正をしたCTPじゃない1.2が早い内に出るのかもね

ロードマップ確認したら、1.3にprotectedサポートの記載が！
年内にprotectedが使えるようになる可能性が出てきた

>>682
ありがとう！
修復インストールではダメだったけど、
アンインスコしインストールでテンプレ出るようになりました

https://github.com/sebmck/6to5
こういうのが出てきたけどtypescriptと競合する？

ie8と互換性のない変換するのはわざわざ使わないかな

鯖で使うにはライブラリとしての安定性に信頼が置けるのかという

ie6 -> HTML5 ?

そこのComparison to other transpilersにもあるけど型チェック必要なければ似たようなプロジェクト以前から複数あって実際競合してる

TypeScriptの本質は名前の通り型定義だから

java + TypeScriptの構成で開発したいんですが、eclipseとvisual studioの両方を使ってスムーズに開発することは出来ますか？
visual studioでTypeScript書いて、eclipseでjava書きたいです

両方の言語で共有して使えるモジュールみたいなの無いし、片方のIDEでの編集がもう片方に即座に検知される必要のある使い方しなければ問題無いべ。
俺はEclipseとWebstormで似たようなことしてる。

EclipseのGUIから起動したTomcatで、Webstormで編集したhtml等の静的ファイルをホストしてるが問題ない（最新のが来ないとか）です。まぁURLとローカルのファイルパスのマッピングのミスマッチは無視で。。

VSギャラリーのJava言語プラグインみたいな奴に期待すると悲しいことになる

TypeScriptは良い言語だけど、VisualStudio以外のIDEがダメだなー

>>702
>Webstormで編集したhtml等の静的ファイルをホストしてるが問題ない（最新のが来ないとか）です
自分も同じ現象で困っているんです。visual studioで修正した内容が、tomcatに反映されないとちょっと厳しい

TypEcsとかeclipse-typescript試してる人はいないの？

あと更新の検出だけならEclipseのワークスペース同期を自動にしてみるとか

>>705
どっちもプラグイン無しよりはかなりマシ
VSと比べると微妙だがサーバーサイド開発で既にEclipse使ってるならまぁありだと思う

https://github.com/microsoft/typeScript/milestones
ここ見るともはや1.3がそろそろリリースされそうな勢いだな
1.2は1.1の致命的なバグFix版の位置付けだけど飛ばして1.3なのかな？

ちなみに1.3は言語仕様が少し変わってprotectedとTuple型が追加される
Tuple型は今まで配列に違う型の値を入れられなかったのが、入れられるようになって
var t: [number, string] = [1, "one"];
が出来るようになるようだ

普通やんないから全然重要な機能じゃないけど、既存のJavaScriptで作ったライブラリ
を使う時に困ってた人はいるかもね

配列というより構造体やね

TypeScriptというかnodejsのharmony仕様を調べ始めたところだが、
ES6の実装状況がまちまちで四苦八苦している。

JS処理系側でサポートされてないと、TypeScriptで記述しても意味ないからなあ。

何言ってんだこいつ

TypeScriptの入門は
http://www.typescriptlang.org/Handbook
がコンパクトだけど必要十分な内容で他のドキュメントは不要とさえ思える

しかしもっと見やすいフォーマットのが欲しいけど見当たらないな

JavaScriptフレームワーク側がモジュール機構を持ってる場合、
TypeScriptの外部モジュールの機構とバッティングしてこんがらがってしまう。
なにかこの辺をうまく説明してくれてるドキュメントはないものか。


たとえばAngularJSとか。

基本的にスーパーセットなわけで、こんがらがるかなぁ
運用ルール次第なんじゃない

javascript -> TypeScript の流れって
perl5 -> perl6 並に糞

>>715
どう糞なのかくやしく

モジュールやクラスのエミッタの拡張ポイント欲しいって話は出てるからMSの人々も現状で過不足無いとは思ってなさそう

多分、TypeScriptもPerlも理解出来てないと思う

朝日新聞みたいに言ったもん勝ちみたいな風潮はいつから始まったんだろう

1.1でもう既に十分な機能ではあるけど、唯一改善して欲しいのが
出力される.jsの空行が全部削除されてる事だ
これは頂けない
多分難しいのかもしれんが、.tsに書いた通りに空行を残してもらえればもう言う事ない

あと、if elseも
1.0
if (...) {
} else {
}
だったのが、
1.1
if (...) {
}
else {
}
になったのもちょっと嫌だな…気にし過ぎかな…

それは嫌

TypeScripとJavaで開発するとき、EcipseとVisualStudioの連携が面倒だなーって思ってたけど
xmlhttprequest使えば、簡単に連携出来そうだねー

>>723
ちょっと言ってる意味が分からん…
Ecipse⇔VisualStudioはツール間の連携
XMLHttpRequestはサーバーとhttpで通信するJavaScript用APIだぞ

>>724
サーバサイドをjava、クライアントをTypeScriptで書いた業務システムを作りたい。
�@ サーバ側はEclipse + Tomcatでプログラムを書きたい(サーバサイドでHTMLの生成は行わない)。
�A クライアント側はVisual StudioでTypeScriptを書きたい(静的なHTMLに対して、Jqueryでいろいろやりたい)。

Eclipse と Visual Studioの連携は難しい ===> XMLHttpRequestでクロスドメインを使うようにプログラムを組めば、両方のIDEを使って開発できるのではないか？

�@ サーバ側はJava + Tomcatでこれまで通り開発 (リクエストはJSON形式)
�A　Visual StudioでTypeScriptプロジェクトを作成
�B TomcatにCrossDomainを許可する設定を行う

こうすれば、Visual Studio内臓のIIS + IEでTypeScriptをデバッグできるなーと思いました。

「Eclipse と Visual Studioの連携は難しい」っつってもそもそもがサーバーもクライアントもJavaScriptでやるんじゃなければIDE間の連携要らなくない？
localhostで動かして必要ならFiddlerでホスト書き換えればCrossDomainすら要らないと思う

>> 726
勉強なりました。
Fiddlerで静的コンテンツをtomcatから配信しているように見せることってできるんですか？

本当はサーバでjava以外の言語を使いたい。だけど、IT土方はリスキー言語を使うことは出来ないんだ

>>727
Javaなんて開発もデバッグもめんどくせえリスキー言語なんて使いたくないわ。

Androidアプリ作るときは仕方なく使うけどね。サーバーサイドじゃ使いたくない。

Javaが嫌なら何で作るんだい

>>729
ヒント：このスレのタイトル

TypeScriptでBackBoneを使うメリットが無い気がするんだけど、気のせいかな？
backboneはclassを提供してくれてるけど、typescriptだと普通にclassあるじゃん
それに、jsを呼び出すから、デバッグする時に面倒な気がするんだ

スレ違いになるだろうが、VSがJavaをサポートすればかなり売れると思う
IntelliJがどれくらい売れてるか知らないけど

Javaは確かに普及はしてるががそんなに重要な言語とは思えない
MSはC#があるし言語仕様的にはC#のほうがいいからJavaをサポートする意味が分からない

J++とかJ#とかややこしい経緯があったんだよ
このスレで言うのもなんだが実行環境の縛りなければサーバー側でTypeScript使いたくはない
ブラウザで動かす前提なら最強の一角だけど、単に言語として見るとJavaScript由来の仕様辛いよ

>>734
俺もそう思うわ

ES6が標準になればletとか使えるようになるからJavaScript由来の変な仕様はほとんど無くなるよ

むしろES6は非同期処理が充実するとか現状でも配列の柔軟性とかメリットも多いと思うけどね

10年後に期待

10年後ってなんだ？
サーバー側はNode.js一択だと思うからオプションで有効にすれば今でもletとかyieldとか使えてる
クライアント側は例によってIE次第だな
スマフォの場合はIE気にしないからじきに使えるようになるかね

https://github.com/Microsoft/TypeScript/wiki/Roadmap
このロードマップが更新されて、1.3のprotectedとTuple型の追加の他に
1.4でUnion Types and Type Guardsが追加されるようだ
interface Settings {
foo: number|string;
}
とか
function process(n: string|HTMLElement|JQuery) { /* ... */ }
みたいに出来るらしい
これでへんてこなオーバーロードの宣言を書かなく済みそう

Type GuardsはJavaScriptに退化してるんじゃないか
実装されても規約で禁止されそう

>>740
なんで？型情報は保存されてるからanyが伝搬していくわけじゃないよ
function process<T>(n: T) { /* ... */ }
と同じでなおかつ型を限定してるだけだと思う

jsでproc(n: any)だったのを型を確定するためにproc(n: number)にしたのにproc(n: number|string)じゃまた不確定に戻ってる
パラメータの型は呼び出された側でなく呼び出す側で揃えるべき
オーバーロードの表現として使うにしても本来関数の実体が別々だったものを実体が一つしかないtsの奇形を促進させたらますますクラスベースと離れていく
オーバーロードの実体以外で許可したらそれもうオーバーロードじゃなくて何でも放り込めるただのjsの関数と違うんかと

>>742
それは不確定とは言わない
不確定なんて言ってたらジェネリックスを根本から否定する事になる

コンパイル時に型が分かる事をタイプセーフっていって変な型を指定した場合に
コンパイル時にエラーになれば、それで問題無い

ジェネリックスを否定したらC++は型が不確定な言語になってしまうな
C++はオーバーロードも出来るわけだが、型が不確定なんて言ってる奴は誰もいないぞ

>>743
実害としてクラスベースで書けないjserがオーバーロードもわからず既存のjsコードにType Guards突っ込んだだけで型定義しましたみたいにもってきそうなのが前段の反対理由
コンパイラでなくコーディングの統一と可読性の問題
そもそもジェネリックやオーバーロードを認めないような極端な話ではない
後段については触れられていないがいかがか

>>744
常に変数に型を2つも3つも書くやつが出てくるかもしれないって事でしょ？
正直そうしないように注意とかするしかないよ
今だってany使いまくれば、型システムを破綻させられるんだから

JavaScriptで出来てる事をTypeScriptでタイプセーフに出来るのであれば
機能として問題無いと思う

JavaScriptとのインターフェースでは使うけどTypeScript側では使わないくらいの規約が良さそう
それはそうとnumber|stringとは別にNum of number|Str of stringのようなの欲しい

>>745
んで、そうしないように注意するしかないことを増やすアップデートを誰が喜ぶんだしかもTypeScriptでということ
コンパイラの仕事を人間に戻すなと

>>747
オーバーロードが書きやすくなるから、少なくとも俺は喜ぶが
少し気にし過ぎだろ…

function process<T>(n: T) { /* ... */ }

って書けば今だってパッと見型が分からないコードは書けるわけで、それより限定してる分マシだろ

>>748
自分一人でやるか品質が保証されている分にはそうだろうがね
大規模開発のための言語だろこれは
オーバーロードにしても型と型に応じた処理の分離していないバグの入りやすいtsのオーバーロードを
ほかの言語より使いやすくお膳立てするなんてバグを奨励しているようなものだ
そういうのは全部jsに捨ててくるべきものだ

>>749
もしかしたら勘違いしてんのかもしれないけど、
interface Settings {
foo: number|string;
}
fooは実行時にnumberとstringにコロコロ切り替わるわけじゃないぞ？
コンパイル時にどっちかの型に決まるだけだ
実行時には型は一貫してんだからバグりやすくはならないはず

>>750
Union Typesについては最初から触れていないが…
これコンパイルで動的型付けしてる？

var x: string | number;
var test: boolean;
x = "hello"; // Ok
x = 42; // Ok
x = test; // Error, boolean not assignable
x = test ? 5 : "five"; // Ok
x = test ? 0 : false; // Error, number | boolean not asssignable

いわゆる直和型みたいなものという理解は正しい？

>>741
C++でいうところの特殊化ってやつだね。

>>752
違う。直和型オブジェクトは存在しない。型指定子に過ぎない。

https://github.com/Microsoft/TypeScript/pull/824
をざっと見たけどこんな感じ？

var x: string | number = "a";

// 実行時の型が string か number か確定していないのでコンパイルエラー
// x.substring(0,0);

if (typeof x === "string") {
　// string だと確定しているのでOK
　x.substring(0,0);
} else {
　// string でない = number なのでOK
　x.toFixed();
}

>>755
何となく理解出来たがType Guardsは、typeofが書かれていたら型が確定してるからOKっていう
面白い仕様なんだな

var x: string | number = "a"; ← この指定がUnion Typesで
if (typeof x === "string") { ← このif文がType Guardsって事かね

仕様書を見てちゃんと把握したいな

Common Lispにもこういうのあるでしょ。
動的型付けの言語だと、こういう型の限定の仕方の方が実行時動的型と整合性がいい。

http://blogs.msdn.com/b/typescript/archive/2014/10/22/typescript-and-the-road-to-2-0.aspx
ブログが更新されたけど、これ見てGoogleがAtScriptなるTypeScriptのパチモンを作ってる事を知った
言語仕様も殆ど一緒で完全に車輪の再発明なのにGoogleは相変わらず節操無いな…

1.2は飛ばして近い内にprotectedが使える1.3が出るようだ
で、1.4でUnion TypesとType Guardsが入ると
仕様は>>755の通りだね

ES6やES7のことを考えれば、複数の型システムのテストベッドがあるのは非常に良いこと。

VisualStudioでデバッグしている時に、ステップインでjsまでデバッグしちゃうけど
これどうにかならんの？

jsまでステップインしたくないよ

>>760
VS使ってないから分からん…
ステップインせずに普通にステップ実行(ステップオーバー？)すればいいだけのような気がする
ステップインって中に入る事だからね

>>761
eclipseだとステップフィルターってのがあるよ

MSのいうところの大規模ってどんくらいなん

ソースコードで１億行くらいだろ

>>764
Windowsの全ソースコードでもそんなにないだろw

ソースコードの行数というより人数を基準にした方がいいだろ

１億人くらいだろ

https://github.com/Microsoft/TypeScript/wiki/Roadmap
Roadmapが更新されてた
ES6の対応は2.0からだったはずだけど1.4からES6のターゲットが追加されて
機能的なサポートも始めるようだ (let const とか)

まだES6をすぐ有効には出来ないだろうが先に実装されてるのはありがたい

>>765
Windows Vistaのステップ数は5000万行らしいねー

getDateをprivate似したい場合どうかけばいいんですか？
こう書くとclock.ts|3 col 3 error| TS1131: Property or signature expectedになりました

interface ClockInterface {
currentTime: Date;
private getDate(): void;
}

class Clock implements ClockInterface {
currentTime: Date;
private getDate(){
}
}

>>770
interfaceにprivateは書けないよ
他の言語でも同じだと思うけど

そうだったんですか
classのほうにだけprivateを書いて
interface ClockInterface {
currentTime: Date;
getDate(): void;
}

class Clock implements ClockInterface {
currentTime: Date;
private getDate(){
}
}
こういうふうにしたらエラーがでなくなりました
でもprivateを付けても付けなくてもコンパイル後のコードの中身が変わらなかったので
typescript上でしか意味がないそうだしつけなくてもいいかもと思いました

privateできるけどしなくていい

var user = {name: "takeshita", age: 20};
これをtypescriptでの書き方を教えてください

class School {
user: {name: "takeshita", age: 20};
}
はだめでした

基本の書き方覚えないで書いてるだろ
ネットのリファレンス一通り読め

typescriptではこう書く

var user: any = {name: "takeshita", age: 20};


classを使う場合はこう書く

class School {
　　name = "takeshita";
　　age = 20;
}
var user = new School();

さらにTypeScript的な感じならこうだな

interface School { name: string; age: number; }
var user: School = { name: "takeshita", age: 20 };

class School {
constructor(public name: string, public age: number) {}
}
var user = new School("takeshita", 20);

SchoolをStudentに変えるべき
その教材は捨ててしまえ

>>774
> var user = {name: "takeshita", age: 20};
↑
これは正しいTypeScriptの書き方
なんら問題無い

ただuserが何型かを明確にさせたいなら>>777の

interface School { name: string; age: number; }
var user: School = { name: "takeshita", age: 20 };

がTypeScriptらしい書き方
classを使うとこの場合は別モノになるな

scoolkiller思い出した

コンパイルした時に複数のtsを、1つのjsにまとめる機能って無いの？
共通部分は1つのjsにまとめて、それを参照する形で業務ロジックを作りたい

ちなみに、VisualStudio使ってます。

プロジェクトのプロパティを開いて
「出力」−「JavaScript出力をファイルに結合する」をON
ファイル名を入れてビルド

>>782
まじかー
サンクス

1.3ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!
Announcing TypeScript 1.3
http://blogs.msdn.com/b/typescript/archive/2014/11/12/announcing-typescript-1-3.aspx

ついにねんがんのぷろてくてっどが！

しかし出力された.jsは相変わらず空行全削除だな…
読み易いJavaScriptを出力するのが目的なんだから何とかして欲しいもんだ

>>784
2012
10/01 0.8

2013
06/18 0.9

2014
04/02 1.0
10/06 1.1
11/12 1.3

この調子で2.0まで駆け抜けてくれ

https://github.com/Microsoft/TypeScript/wiki/Roadmap

>>758
angular.jsのためにアノテーション加えたかったんだろう

TypeScript 1.3.0 変更点
ttp://qiita.com/vvakame/items/0b5060de5566f210479b

>>789
> しかしまぁご覧のとおりanyを使うと普通にアクセスできてしまうので、僕個人の感想としてはあんまり意味がないですね。
> privateも使わないで書こうマンだよ〜。
とても本を書いてるとは思えないド素人発言だな…そもそもprotecedが無いのは欠陥だったとも言える

ちなみに、TypeScriptリファレンスは糞みたいな本なんで買わない方がいい
何で知ってるかというと俺が買ってしまったからw

ほかの言語でもprivateなしで書いてるんすかね…

多分コメントに、この変数は外部からアクセス不可とか書いてんだろうねw

C#やJavaとかのprotectedと違ってthisから上位クラスのprotectedにはアクセスできるけど
自分以外の上位クラスのインスタンスのprotectedには触れないっぽいね

RubyのprivateやScalaのprotected[this]の挙動に近いけど
同じクラスであれば自分以外のインスタンスのprotectedでも触れちゃうとこが違うな

>>793
> 自分以外の上位クラスのインスタンスのprotectedには触れないっぽいね
C#とかJavaってそうなんだっけ？
とりあえずC++はアクセス出来ないからC++とは同じだな

> 同じクラスであれば自分以外のインスタンスのprotectedでも触れちゃうとこが違うな
これもC++と同じだった

Roadmapみるとabstract classesは2.0の予定になってるけど早く実装して欲しい
virtual overrideの管理にプログラマが気を付けなくちゃいけないのが嫌だな

だれか急いで１．３対応の入門書だしてくれ

1.3は1.0にprotectedとTuple型が追加されてるだけだよ

TypeScriptってJavaScpiptに対するJScriptみたいな位置づけになるの？
ECMAScriptの大部分の拡張とTypeScriptの拡張はかなりかぶってるよね。
.jsにTypeScript書いたらそのまま動くようになったりする？

TypeScriptは名前の通りJavaScriptに型を導入する事が最も大きな特徴
プラスしてJavaScriptを拡張してるが、ほとんどはECMAScript6の機能に準じてる
要するに
TypeScript≒ECMAScript6＋型
と考えていい (とはいえ、まだ色々実装途中ではあるが)

> .jsにTypeScript書いたらそのまま動くようになったりする？
無理

>>798
ランタイムはライブラリしか持たないから全然違う。

>>798
アンダース氏が設計した新言語による次世代JavaScript開発とは？ (1/3)
http://www.atmarkit.co.jp/ait/articles/1301/18/news087.html

TypeScriptとは何かを、日本語で最も分かりやすく説明している記事だと思うから読んでね

https://github.com/Microsoft/TypeScript/wiki/Roadmap
>1.4
>New --noEmitOnError

何か追加されてた

>>802
それはエラーになった時に.jsを作るなというオプションだ
ビルド中にエラーなのに.jsが作られると不都合がある時に便利なやつだ

https://github.com/Microsoft/TypeScript/wiki/What%27s-new-in-TypeScript%3F
ちなみにこんな分かり易いページがあったぞ
これによると、Roadmapに書いてないけど1.4ではCで言うtypedefが導入されるな
コールバックの型を毎回正しく書かなくてよくなるのは助かる

switchのcaseラベルが重複してても何のエラーにもならないな…これはアカンよ
tslintでもワーニングが出ないから、ひとまず目視で確認するしかないなぁ

ウォーニンｇ

TypeScript 1.4 sneak peek: union types, type guards, and more
http://blogs.msdn.com/b/typescript/archive/2014/11/18/what-s-new-in-the-typescript-type-system.aspx

Flow | A static type checker for JavaScript
http://flowtype.org/

http://qiita.com/tags/flow

facebook版TypeScriptであるflowの動向も

また無駄な再発明するのか

TypeScriptで最も価値があるのはlib.d.tsだ (最近は分割されてlib.*.d.tsだけど)
ブラウザ内蔵オブジェクトに正しく型を付けているのはTypeScriptだけ
これを真似しようとしたり使ったりしようとすれば単にもう一つTypeScriptが出来るだけだ

angular.jsいいね

Union types

var x = [1, 'hello']; // x: Array<string|number>
x[0] = 'world'; // OK
x[0] = false; // Error, boolean is not string or number

これって地味にべんりなのか？
コマンドラインの引数で引数が ’abc’ 又は 1 とか
’abc’ 1 みたいなストリングと数値
内部で処理するときに ’abc’ はストリング 1 は数値であることが確定かつ保障された状態なので処理が楽みたく

>>812
それはTuple型だ
x: Array<string|number>のstring|numberがUnion typesといえる
普通やらないし、JavaScriptエンジンは配列に別の型を入れると遅くなる問題がある

ヘジはLightweightな言語に細かい便利機能詰め込むんじゃねーよ
ルーズだけどシンプルだからスクリプト使ってるのに
複雑なことしたいならstatic strong typingなC#でやるっての

>>814
細かい便利機能じゃないよ
既存のJavaScriptライブラリとかに配列内に別の型の代入する事を要求するものがあった場合に
今までだとanyにするしかなかったのをちゃんとタイプセーフに出来るようにしただけ

Union Typesのおかげでanyを全く使わなくて済むようになるから重要な機能だ
TypeScriptオンリーの場合は使わない機能とも言えるがJavaScriptとの連携を考えれば必要だな
C#もdynamicが導入されて動的言語になってるからTypeScriptと同じ立場と言える

もともとanyで出来たんだ
タイプセーフでコンパイル時に弾くんだね

>>813は微妙に間違えた…
Tuple型は
var x: [string, number] = ['hello', 1]; // OK
x[0] = 1; // NG
x[0] = true; // NG
var x: [string, number] = [1, 'hello']; // NG
で、

1.4でUnion Typesを使うと
var x: Array<string|number>
var x = ['hello', 1]; // OK
var x = [1, 'hello']; // OK
x[0] = 1; // OK?
x[0] = true; // NG?
かな

1.3で型を書かないと
var x = ['hello', 1]; // OK → x:[any, any] になってるっぽい
x[0] = true; // OK

まとめると…配列に違う型を入れる場合はTuple型を使うか1.4以降のUnion Typesを使って
ちゃんと型定義しないと、[any, any]になってしまうってことか

javaをやっている感じで、ファイルを分割しているんだけどさー
やっぱり、ファイルを分割するとパフォーマンス落ちる？

パフォーマンスが実行速度の事なら変わらないよ
最初の読み込み速度は多少遅くなるだろうね

>最初の読み込み速度は多少遅くなるだろうね
これって、jsの読み込み速度？

>>820
そうそう
ただ、1ファイルにまとめてjsを書き出せるから最後にまとめれば問題無いんだけど

出力ファイルは結合すればいいんだけど分けすぎると依存関係が理解不能になって死ぬよ

ちょっと体験してみたいけど、どうすれば良い？

Playgroundで試せ
http://www.typescriptlang.org/Playground/

>>822
それは単に設計する時の問題だろw
TypeScriptだと理解不能になりやすいとかあるのか？

ファイル読み込み順間違えると落ちたり、相互参照で動かせないコードが書けたりする程度

>>826
ファイル読み込み順間違えるとエラーになるのは確かにあるな
コンパイル言語ではあるが実行はスクリプトで頭からだから、アレ？と思うことはある
ただ、相互参照で動かせないコードが書けたりするのは、どの言語でも有り得るぞ

>>826
つうか本質的には両方同じ事を言ってるな…
ファイル読み込み順問題で分割せざるを得ない事はあるか

ソース同じなのに依存関係壊れてるファイルを出力することがたまにあるのが困る
ウォッチでなしに

Facebook、JavaScript用の静的型付けチェッカー「Flow」をリリース
http://sourceforge.jp/magazine/14/11/20/163800
facebook flowでHTML5 Canvasデモを作ってみた
http://ics-web.jp/lab/archives/3611

AtScriptってなんだろう？ 〜 めも 〜
http://albatrosary.hateblo.jp/entry/2014/11/20/131206

スレチ
面倒
3行

最後だけ読んだけどES6先行実装したところでどうせ普及するまでにはTypeScriptも対応するのだからアドバンテージではない
それより仕様変更の追従で互換性が死んだり冗長化するのが不安
まずVS相当のIDEだせ話はそれからだ

>>5
VSの2013 Communityがリリースされた今、このレス見ると、微笑ましく
なるね。MSがサーバーサイドへ収益源をシフトしようとしてる中では、Eclipse
やXcodeみたいなものに、プラグインじゃないにせよ、技術提供することは容易
に考えられる。

え、開発環境としてのWindowsを売ろうとしてるんでしょ？

実際にはlanguage serviceとかいう入力補助や型ヒント等の開発補助ツールの為の機能は既に提供されてるよね？
まぁ俺IDEの中の人じゃないし知らんけど。

>>830
情報ありがとう
TypeScript はもう古いんだね

>>836
下記にくさだとか、色々な大規模開発上の問題点は、フレームワークが
解決してくれてるしな。HTML5などなど色々と登場してる中では、昔のよ
うなJavaScriptではない。

フレームワークすげぇ

>>833の書き込み見て、このスレが２年前からあることに驚いてしまった
そして安定の>>2で笑ってしまった

>>830みたいなWebの連中の、品質や互換性を軽視したいい加減な仕事のやり方は言語作りにはそぐわない
実際、Web初の言語で一番成功したのがCoffee(笑)だもんな

初？発？

>>830は俺だが、TypeScript類似言語の動向や差異を日本語で書いてあるものを
貼っておけば分かり易いからで、叩く意図はない

>>836
古いのではなく先取りしている
だから他社が追随してきた

リンクだけ張られてもだから何だわ

flowを少し見てみたけど、ほぼ完全にTypeScriptのパクリだった
private指定が無かったんで、JavaScriptに無い機能は追加しない方針なんだろうね

しかし、言語設計とか一番大変なところを完全にパクっといて自社プロジェクトっぽく
発表してるのは、企業理念を疑うレベルだな

Googleの黒魔術はまだスルーできるけどFBは個人情報分析くらいしか技術的に見れたところないのでは

2014-11-25のJS: Chrome 39 Beta、デバッグTips、Facebook Flow
http://jser.info/2014/11/25/chrome39-debug-flowtype/

typescriptの変換通ればJSHintなど通す必要ない？

tslintにしてる

tslintいいよー
デフォで有り得ないぐらいチェック厳しいけど、デフォぬるくて気がつかないよりはいい
適宜調整してちゃんと通せばJSHintはいらないね

>>848-849
あんがと、なるほどtslintか。

テストはqunitなどのJavaScript用でいいかな？

>>834
それならば.Netをオープンソース化なんてしないだろ

PCが衰退し様々なスマフォやタブレットなどに移行していく昨今、来るWEB OS時代（ChromeOSとかfirefoxOSとか）にソフト環境をどうするのか？という問いに対するMSなりの回答なのさ。

AppleやGoogleはすべて捨てろ、新しく覚えろ、作りなおせ、毎年買えと言ってる。
イノベーションとか革新的に再定義したとか言い出して誤魔化しているが冷静に考えれば
キチガイじみてる。

それに対して、既存リソースをWEB OS時代に継承できますよ。というMSからのメッセージなのだろう
つまり、OSとかPCを捨ててその上側持って次世代に行きますよってことだな。

20年前を彷彿とさせるな

オープンソース化されたのは.NETではなく、.NET Coreである点に注意

既存リソースの継承というより、
.NET Core用リソースへの投資を促す為でしょ

これを機に鳴かず飛ばずな.NET Coreの状況を改善しようとしてる

monoの立場が微妙になってきたがそれはそれで存続するんだろうな

結局monoにはならなかったか…

xamarinでこれから儲けたろ！って思ってた所に
本家から目をつけられた感じだなｗ

xamarinはmono自体を売るのが商売じゃないから、正直たいした影響は無い気がする
顧客としてはC#でAndroidアプリを作ったり出来れば何でもいいんだろうし

現在さっぱり金になってない.net/mono on Unixサーバーの法人向け事業を
MSの支援を受けながら本格的にやれるんだから、xamarinにとって悪い話ではないだろ
うまくいけばXamarin studioなんかよりよっぽど安定して稼げる

TypeScriptの行く先
http://qiita.com/vvakame/items/bf4d1e339d5815026fbb

ECMAScript 6 compatibility table
http://kangax.github.io/compat-table/es6/

TypeScriptが各処理系のES6対応状況一覧に追加

TypeScript 1.3 (7%)
6/9 arrow functions
3/5 default function parameters
YES rest parameters
1/3 object literal extensions

>>859
> ECMAScript 6 compatibility table
IE(TP)のES6の準拠度がはんぱねー
VS+TypeScript+IE(TP)で最強のアプリ開発環境になりそうな悪寒

>>858
いや、そうはならないと思うよ。

実際にUNIXサーバでMonoを動かして.netをどうこうしようなんて考える客は
殆どいないし、そもそもMonoの互換性は低い（大体、.netだけでプログラム組んでる
奴なんて殆どいない）。

.net使うならIISを使うし、開発環境はVSオンリー。Xamarinなんて初めから相手に
しないよ。MSが公式に.net frameworkをUNIX向けに完全ポーティングしてくれるな
らともかく、今回の公開はあくまでもCore部分のみ。そっから先はなんとかしろって
話だからね。

もともと、Xamarinに高い金払って開発するような価値も余地もないよ。

>>858
いまのMSはクラウドサービス押してるのもあり、
サーバとクライアントは、Adobeの動画配信ビジネスみたいにシフトして
開発環境はVSが売りだと分かってるらしいが、ここは展開の実現性も必要性もあまりなさそう。
OSコンテナ技術やライセンスフィーの問題に対応できれば、1000台を10分で投入するような効率優先のSaaSやサービス展開に対応出来てサーバ側の展開は必要なくなると思うので、どっちが先になるかだな。

TypeScriptから生成されたjsを動的ロードしている人いる？
国内情報だとrequire.jsの情報とか少なくないか

ちゃんとTypeScriptの流儀にならってinterface経由で依存関係を扱うようにしていれば
動的ロードでも特に問題になるところは無いと思うが

TypeScript 1.3とECMAScript 6に向けたマーチ
http://www.infoq.com/jp/news/2014/12/typescript-ecmascript-6

TypeScriptの注目の型関連issue
http://teppeis.hatenablog.com/entry/2014/12/typescript-hot-issues

FacebookがJavaScriptの型チェックを提供するFlowをオープンソース化
http://www.infoq.com/jp/news/2014/12/facebook-flow-javascript

「生JavaScriptで十分」な人にこそTypeScriptをおすすめしたい理由
http://mzsm.me/2014/12/23/advent-calendar-2014-typescript/

TypeScript でも充分とは思えない

>>867
例えばどんなところが？

右クリック＆ドラッグでコピー出来なくなってる

2015-01-06のJS: ESLint 0.11.0、Browserifyとwebpack、TypeScriptの本
http://jser.info/2015/01/06/eslint0.11-browserify-webpack-typescript/

TypeScript in Definitelyland
http://techbooster.github.io/c87/#typescript
型の国のTypeScript
http://typescript.ninja/typescript-in-definitelyland/

開発者の年末年始休暇も終わっただろうし、1.4期待age

VSがハングアップするバグはよなおしてけれー

>>871
https://github.com/Microsoft/TypeScript/milestones
ここ見ると88%だから、まだ数ヶ月掛かるような気がする
100%になってもリリースするまで1ヶ月ぐらいは様子見てるし

>>873
http://blogs.msdn.com/b/typescript/archive/2014/10/22/typescript-and-the-road-to-2-0.aspx
>@Simon - We've been trying to put out a release every 6-8 weeks, but sometimes they take a bit longer to bake.

http://www.infoq.com/jp/news/2014/12/typescript-ecmascript-6
>TypeScriptのProgram ManagerであるJonathan Turner氏は、「6〜8週間ごと」にリリースを提供して、
TypeScript GitHub リポジトリですでに利用可能な言語とツール機能を構築していくTypeScript 2.0ロードマップを示した。

昨年の11月12日に1.3が出てから8週間経つし、近い内に1.4来るかなと思った
それと、今月21日のWindows10のイベントに合わせるかなとも考えたんだ

https://github.com/Microsoft/TypeScript/wiki/Roadmap/4eb16e36ab6b3d9749b10d584c3cca3744cbd66d

ロードマップが更新されて、SymbolsとComputed propertiesの対応が1.4から1.5に先送りされてる

>>873
1.4.1の項目が追加されて、1.4の方は進捗度が100%になってるよ
もしかしたら今週か来週あたり出るかもしれない

これからは言語仕様追加版の合間に、不具合修正版を細かく出すのならいいな

>>876
ほんとだ
無理やりな感じもするが、定期的なアップデートを重視してるのかもね
1.4は近いうちに来そうだ

1.4きたな

汚ね

Announcing TypeScript 1.4
http://blogs.msdn.com/b/typescript/archive/2015/01/16/announcing-typescript-1-4.aspx

これでES5の範疇に関してはひとまず完成形と言えるだろうね

--target ES6 でコンパイルしても今までのES5の機能を使ってる限りは多分全く同じjsが出るな
classとか=>がjsに残ったりしないから、ちょっとつまらんな

ES6にしたらそのまま型情報だけ消えてそっくりの文法で出力されると思ってたわ。

class People {
private age: number;
constructor(n: number) {
this.age = n;
}
getAge() {
return this.age;
}
}
これをコンパイルしてvar obj = new People(10);console.log(obj.age);すると10と表示されて
privateの意味がないんですが何故ですか？

privateはコンパイラへの指示であってコンパイル結果であるJavaScriptにprivateなんて概念無いから

>>882
そうなるのは2.0からなんだろうね

生成されるjsに型やアクセスレベルのチェックを入れるオプションがあってもいいとは思うが
開発スピードを最重視してるみたいだから二重開発みたいになるのは嫌なんだろうな

>>886
TypeScriptオンリーで開発してる場合は必要無い機能だ
JavaScript用のライブラリ作る時にはあった方が便利かもしれないけど、AtScriptがやろうとしてるな
あと、アクセスレベルのチェックって不可能だと思うけどな

８８８

>>886
それやるのブラウザのJSエンジン側じゃねという感じ

Chrome専用ですね判ります

Dar...いや、なんでもない

Microsoft、「TypeScript 1.4」をリリース
http://www.softantenna.com/wp/software/typescript-1-4/
TypeScript 1.4.1 変更点
http://qiita.com/vvakame/items/69efc1c6a3b91876330d
TypeScript 1.4がいい感じ
http://d-poppo.nazo.cc/blog/2015/01/typescript-1-4/
Union Typesは直和型ではない
http://d-poppo.nazo.cc/blog/2015/01/union-types/

最近のFlowtype事情とReact+Flowtype連携
https://gist.github.com/teppeis/a48558a71a98d6bee6c9

https://github.com/facebook/flow/blob/master/Changelog

Flowの動向も一応

このスレ書き込んでるの知ってる人ばっかりじゃないかと思えてくる

寝てる間に自分が書いてる可能性もあるな

蝶が書き込んでいるスレと聞いて

>>892
> Union Typesは直和型ではない
> http://d-poppo.nazo.cc/blog/2015/01/union-types/

圏論とか全然分からんが
> じゃあTypeScriptでの直和型って何なのよ？
で出てるサンプル見た限りだと、Union Types + Type Guardsとやってる事は一緒な気がした

なんで、TypeScriptのUnion TypesはType Guardsと合わせて使う(想定された使い方)ことで
直和型と言って問題ないと思われる

>>892
おまえわかめちゃんだろ

>>897

(* OCaml / F# の直和型 *)
type sum = L of int | R of int

-- Haskell の直和型
data Sum = L Int | R Int


// TypeScript の Union Types

// type Sum = number と同じ
type Sum = number | number

var x: Sum = 42

// どっちの number?
if (typeof x === "number") { ... }

>>899
なるほど、それは分かりやすい説明だ
直和型とは言えないんだね

ついでに質問だけど、>>897のサイトで
> 直和型は、一般には「左右どちらの値を持っているか知っている」
といきなり説明されているけど、それは直和型の前提なのかい？

>>900
型理論的? な厳密な定義は知らないけど

a 通りの値をとる型 T と、b 通りの値をとる型 U、があるときに
直和型 (T | U) がとる値は (a + b) 通りになる

というのが自分の直和型に対する理解。

たとえば、型 boolean の値が true, false の 2 通りあるとして
boolean と boolean の直和型 Sum

　// F#
　type Sum = L of boolean | R of boolean

がとる値は L(true), L(false), R(true), R(false) の 4 通り。
直和型の定義を満たすために
「左右どちらの値を持っているか知っている」 必要があると思う

>>901
返答遅くなったけど、分かりやすい説明どうも

ま、区別できることにあまり実用性を見い出せないが、関数型言語とかは理論に忠実(？)に
実装してるから区別できるようになってるという事は分かった

>>881
classはまだ仕様が完全に固まってないんでしょ
最近もsuper()の仕様が変わったばかりだし

http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#january_15_2015_draft_rev_31

spartanでJSコンパイルなしに動く可能性ある？

標準仕様無視してそういう事したらまたIEの二の舞じゃんｗ

多分VBScriptも動かないんじゃね？

>>905
標準仕様的には、scriptのtypeで言語は決められるでしょ？

現状typescriptがコンパイル無しで動いてもそこまで嬉しくない

ttp://www.buildinsider.net/web/spartan/01
独自拡張はやめるってさ

>>908
またUIも同時に変えるんだなｗ
レンダリングエンジンだけまず変えればいいのに。

>>909
レンダリングエンジンは同じだぞ

>　ちなみにWindows 10のIEは、Spartanと同じレンダリングエンジン（詳細後述）が採用される予定である。

IEコンポーネントブラウザと一緒で、こういうものはコアのレンダリングエンジンがあって
そのレンダリングエンジンが備えている拡張機能を使って様々な機能を実現している。
JavaScriptなんかも同じ。

SpartanはActiveX対応などの拡張機能や互換機能を取り除いて
IEコンポーネント以外の部分を変えたものになるんだろう。

まあ、レンダリングエンジンだけ先に変えろというのは正しくて、
それをいままで実際にやって来たんだけどね。

つまり、IE8、IE9、IE10、IE11と徐々に標準に準拠するように
レンダリングエンジンを変えてきた。
これをやらないで一気に変えてしまうと互換性問題が発生するからね。

そしてレンダリングエンジンの変更が終了したからUIの変更に手を付けた。

>>910
Spartanの話だよ。

IEも搭載でこれ以上バージョン上がらないとなるとむしろしぶとく残り続けそう

>>912
Spartanの話だよ？

新エンジンEdgeHTMLがデフォルトって書いてあるね

>>914
SpartanはエンジンもUIも同時に変えてるだろ。

「Project Spartan」が実装するデュアルレンダリングエンジンとは
http://news.mynavi.jp/articles/2015/02/02/windows10report/

>>916
バージョンアップしただけだよ。

俺が言ってる、"変える" というのは
Chromeのレンダリングエンジンから
Firefoxのレンダリングエンジンに
変えるようなレベルの話をしていて。

ChromeのBlinkのバージョンなんたらが
バージョンかんたらに変わるようなレベルの話じゃない。

>>917
結局IEとSpartanどちらもデュアルレンダリングでデフォルトが違うっつーわけね

>>918
エンジン設計のポリシーが変わってるんだが。

IE11の設計ポリシーとは変わってないよ。
ほぼ使われない過去のIE互換機能が無くなっただけ。

IE11はブラウザ

そうだだね。Tridentだね。
Tridentの設計ポリシーは変わってない。
ブラウザのポリシーを変えるだけ。

増改築の繰り返しでわけわかめになったtridentに代わって
一から再設計したEdge使うって話じゃないの？

EdgeはTridentをフォークして作ったtte
ちゃんと書いてあるだろ

フォークしたっつtteも
ほとんど別モンだろうな

なんで引き算でやってるんだろ？
再構築、リファクタリングなら必要なものだけを足し算でした方が早そうなのに

たてました

Spartan (EdgeHTML)
http://peace.2ch.net/test/read.cgi/win/1422875493/

>>929
再構築、リファクタリングは一般的に
必要ないものを取り除くことなんだけど？

新しい機能を追加する前（後にやることもある）に、
既存のコードを整理する。要らない所があれば消す。
この部分が、リファクタリングだよ。

リファクタリングは既存の動作を変えないことで
機能追加をリファクタリングとは言わない。

含まれる

node.js 0.12.0 でも tsc は問題無く動いた
そんだけ

Roadmapの1.5の項目に追加があった
https://github.com/Microsoft/TypeScript/wiki/Roadmap
> Support for let and const on ES3/ES5
これマジか！グッジョブと言わざるを得ない

> Support for tagged string templates on ES3/ES5
意味が分からん…

> Expose a new editor interface through TS Server
これは楽しみだ
VS以外でもメンバー補完とかが簡単に実装出来るようになりそう

>>931
これも1.5に追加、と言うより2.0から前倒しされてるよ
>Support for ES6 Modules

async/awaitも早めに入れて欲しい

ダックタイピングのせいで型だけで整合性がとれないのが非常に残念

>>933
そのための interface いう認識だったのだが、使えないケースがあるってこと？

>>934
StringからSafeStringを定義してもstringが入るじゃん？

>>935
SafeStringに何らかのメソッドを追加すれば弾かれるけど、何も追加しない場合の話？
strong typedef を想定しているのかな？ それができる言語って結構限られると思うけど。

何も追加しない場合の話
Haskellのように型だけで安全を確保したかった

>>935
class SafeString extends String {
はエラーになるけど、定義ってどういう事だ？

>>938
interface SafeString extends String {}
var str: SafeString = ""

interface にダミーメソッドを追加してデフォルトだと弾けるようにして、
キャストしたいときはanyを経由させてコンパイラを騙すくらいしか思いつかない
interface SafeString extends String { dummy(): void; }
<SafeString><any>"ABC";

>>939
ES6だとStringのサブクラスが作れるからそれ待ちだな
それか普通に包含すればいいじゃん

>>939
class Dummy {
　private _dummy: any
　constructor() { throw "Dummy" }
}
interface SafeString extends String, Dummy { }
function SafeString(x: string) { return <SafeString><any>x }
function unSafeString(x: SafeString) { return <string><any>x }


var s0: SafeString = "" // コンパイルエラー
var s: SafeString = SafeString("abc")
s._dummy // コンパイルエラー

class FakeSafeString extends Dummy implements SafeString { ... }
var fake: SafeString = new FakeSafeString() // 実行時エラー "Dummy"

>>942
Cool

declare class SafeContent {
private safe_: boolean
}
interface SafeString extends String, SafeContent {}
function SafeString(str: string): SafeString {
return <SafeString><any>str;
}

var unsafe: string = "";
var safe: SafeString = SafeString("");
var err1: SafeString = "";
var err2: SafeString = new SafeString("");

>>932
自己レスだが、早速来てたわ

https://github.com/Microsoft/TypeScript/wiki/Roadmap/21d94626ac56a8e4441091f4134f1be740399ae3
>1.6
>Generators
>Async/await

>>944
うお！2.0がどんどん空気になっていく…
あとはvirtual,overrideキーワードが実装されれば俺的にはもう十分

http://techcrunch.com/2015/03/05/microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/
AngularJS 2.0 は TypeScript で開発を進めることに

AtScriptとは何だったのか

>>946
Angular 2: Built on TypeScript
http://blogs.msdn.com/b/typescript/archive/2015/03/05/angular-2-0-built-on-typescript.aspx

これ見ると1.5に実行時型情報のサポートを追加するように見えるな
追加されると何がどううれしいのかは全然分からん…

Angular 2フレームワークとTypeScript言語でMicrosoftとGoogleが協働
http://jp.techcrunch.com/2015/03/06/20150305microsoft-and-google-collaborate-on-typescript-hell-has-not-frozen-over-yet/

AtScriptが言語としてデビューしたのは昨年の10月だが、
今後はAtScriptという名前は消えて、TypeScriptに統一されるようだ。

Angular 2はAngularの旧バージョンとの互換性が完全でないので、
デベロッパコミュニティからの批判がとても多い。
Microsoftが作った言語を使うことも、一部の人たちは気に食わないようだ。
でもこれは明らかにTypeScriptの勝利であり、
しかもそれは、昨年1.0がリリースされて以来、着実にユーザ数が増えているのだ。

しかしTypeScriptをパクった言語って他にも幾つかあった気がする
労せずおいしい所だけを持っていこうとするのは何か解せないものがある

ただTypeScriptが刺激を受けたのか進化がやたら早くなったのは良い影響といえるかな

>>949
「TypeScriptをパクった」といえるほど独自性あるっけ？
構文はそのままに型情報を付加するっていう基本部分は、遥か昔からいくらでもあるでしょ。
Python系であったのは覚えてる。

ヘタに拡張せず、型情報とES6の先取りに絞ったMSのセンスは褒めたいけど。

AngularのTS向けにVS以外のIDEがさらに使いやすくなるといいね。

TSはHaxeやCoffeeScriptなどの後に出てきた、センスのいいやつというぐらいの認識ぐらい。

>>951
TypeScriptはJavaScriptの上位互換というか完全版とも言うべき言語
だからHaxeとかのAltJSと違って、TypeScriptを選択することでデメリットは全く無いと言ってもいい
(完全に主観だが)

CoffeeScript のゆるさが好きな漏れには
TypeScript

の良さがいまいち判らない

普段は C / C++ / Python 使いです

>>953
JavaScriptを使ってる人がTypeScriptにしてもデメリットが少ないだろうってだけで
CoffeeScriptを否定するつもりも全く無い

言語の良い悪いは結論が出る話じゃないしな

ただ、今後廃れる言語は使いたくない。
TypeScriptとCoffeeScriptだと、Type優勢なの？

安定のヘルスバーグだからね

ライブラリ使用時の若干の煩わしさがもっとスマートに解決出きる様になったら
手を出そうかと思う

googleがTypeScript使いだしたからな

http://qiita.com/Cat_sushi/items/04abb9a1d248131bf5c0
＞10月に投入されたAngular 2はAtScriptで記述された、より良く、より速いフレームワークです。
＞ここで、AtScriptは当初からTypeScriptの拡張です。
＞
＞重要ポイント: Angular 2はこれまでもずっとTypeScriptで構築されてきました。

言いたいことは分かるが、いまいち納得いかない…

Angular はワシが育てた(キリっ)

煩わしいし、angularから離れてbackbone.jsに戻ろうかな