Archive - linq.js
無限リピートの幸福
- C# JavaScript linq.js - 09.09/09
Reactive Frameworkが、結構に無限リピートな感じなので、関連してC# Linqでどう書くにあった13日金曜日問題を今更書いてみた。n番煎じ。
// 今日から2013年12月31日までの、13日の金曜日とその総数を表示してください。 // 「今日」を無限リピートという方針で書いてみたりして(総数は省略) // 利点はTodayを変数として外側に定義する必要が無くLinq内に閉じ込められる // Toを求めるのに足したり引いたりする必要がなく自然に書ける、の二つかしらん // 「まで」という問いに対してTakeWhileで解答するのは自然で良いと思う Enumerable.Repeat(DateTime.Now, int.MaxValue) .Select((d, i) => d.AddDays(i)) .TakeWhile(d => d.Year < 2014) .Where(d => (d.DayOfWeek == DayOfWeek.Friday) && (d.Day == 13)) .ToList() .ForEach(d => Console.WriteLine(d.ToShortDateString()));
TakeWhileが好きです。問題文に対して、自然に解答出来るような気がするので。「今日から(Repeat)」「2013年12月31日までの(TakeWhile)」「13日の金曜日(Where)」。実に自然に記述できる。いやまあ、Repeatが直感的かというと結構微妙なところではありますが。Rangeでfrom,toのほうが自然だろ常識的に考えて、というのも確かなんですけど、Rangeだとtoを作るのに計算式が必要ってのが、ちょっと違うかな、と。
Pizza (programming language)のexampleにもあるような、Streamを始めとして何かを無限リピートしてTakeWhileで終了条件を設定、というのはパターンとして結構幅広く使える、と思う。ある種のデザインパターン。イディオムイディオム。参考リンクはC# 3.0 と while(true) と Iterator - NyaRuRuの日記この辺り。
例えばVS2010から搭載されるEnumerable.Zipや、あとCycleを定義してみる。
// この二つを混ぜ合わす(VS2010で搭載されるZip関数) var seq1 = Enumerable.Range(1, 10); var seq2 = Enumerable.Range(10, 10); Enumerable.Repeat(new { e1 = seq1.GetEnumerator(), e2 = seq2.GetEnumerator() }, int.MaxValue) .TakeWhile(t => t.e1.MoveNext() && t.e2.MoveNext()) .Select(t => t.e1.Current + t.e2.Current); // ここがZipのSelectorの部分 // foo,bar,hoge,foo,bar,hogeを無限に繰り返す var elements = new[] { "foo", "bar", "hoge" }; var cycle = Enumerable.Repeat(elements, int.MaxValue).SelectMany(ar => ar);
Linqのお陰でかつてない勢いでint.MaxValueを使っているこの頃。Repeatも万能ですねえ。いやまあ、もう素直にAchiral使えよって話なんですが、標準メソッドのみで粘るのも面白くて。そういえばでついでなのでlinq.jsでもやってみた。
// JavaScriptはAddDaysがないので副作用全開でTodayを // setHours(24)で翌日にしてしまう、という方針でやってみた E.Repeat(new Date()) .Do("$.setHours(24)") .TakeWhile("$.getFullYear() < 2014") .Where("$.getDay() == 5 && $.getDate() == 13") .ForEach("alert($)");
DoはReactive Frameworkにもありました。副作用を加えた上で素通しするメソッド。副作用は嫌なものです。汚いです。何が嫌かというと、動作を考えるのに見る範囲を広げなきゃいかんところかなあ。そしてLinqの何がいいかというと、見る範囲が物凄く限定される(ラムダ式一文だけを見ればいい)と思っている。だからLinq内でクロージャ(というか外部の変数をキャプチャして使う)もあんま好ましくないし、C#クエリ構文のletも好きじゃない。なるべくなら使いたくない。長文耐性なのは分かるけれど、カッコやインデントがなくてスマートだけれど、その分だけスコープが不明瞭になるという側面が否めない。まあ、letが必要なシチュエーションをSelectManyでやると、大抵はもっと奇怪になるのですけど。
んでまあ、この場合だとAddDaysのかわりにnew Date(year,month,day)で新しいのを作れば副作用なくSelectが使えるわけですが、ありきたりで面白くないと思ったので別な方向に走ってみた。というか、無限リピートは、無限リピートする何かに対して副作用全開で操作を加え続ける、という形の方が面白いというか実用的というか普通だとは思う。冒頭の例みたいなやつだと、別にRangeでよくね?って感じですし。Haskellじゃないんだから、潔癖症にならずに、副作用といかに楽しくお付き合いするかが大事なのですかね。
あ、ちなみに$は引数が一つの場合の省略記法です。こういった機能はScalaにもある。引数が一つのみの場合が大半なので、記述がグッと縮まるし、何よりも引数名を付ける必要がないのが嬉しい。C#でも使えるようになると嬉しいなあ、とずっと思ってるんですが中々どうして無理なんですかねえ、残念。
JavaScriptで要素追加するやり方
- JavaScript linq.js - 09.08/27
ド素人がjQueryとprototype.jsではどう書くのかな、と思っただけです。メジャーな両者ですが実はまともに使ったことがないのです。困ったことに。しょうがないので見よう見まねで書く。
<!-- このselectにoptionを一個追加する -->
<select id="selectID">
<option value="1">hugahuga</option>
</select>
<script type="text/javascript">
// 素のJavaScriptその1(古臭いというか微妙な……)
var option = new Option("要素", "属性");
var select = document.getElementById("selectID");
select.options[select.options.length] = option;
// 素のJavaScriptその2(これはダルい)
var option = document.createElement("option");
option.setAttribute("value", "属性");
option.appendChild(document.createTextNode("要素"));
document.getElementById("selectID").appendChild(option);
// みんな大好きjQuery
$("<option>").attr({ value: "属性" }).text("要素").appendTo("#selectID");
// 何だかんだで好きなprototype.js
var option = new Element("option", { value: "属性" }).update("要素");
$("selectID").insert(option);
// linq.js + linq.xml.jsの関数型構築
var option = X.Elem("option", X.Attr("value", "属性"), "要素");
X.ID("selectID").Add(option);
</script>素のJavaScriptその1はねーよ、というわけで、その2をいかにスマートにやるかという話。だと思う。jQueryのappendToが合理的というか便利なのは分かるけど、キモく感じてしまう。んで、どれが好きかっていたら、当然自分で作ってるlinq.jsのが一番好きですよ(笑)
// linq.js + linq.xml.js var options = E.RangeTo(1, 12).Select(function(i) { return X.Elem("option", X.Attr("value", i), i + "月"); }); X.ID("selectID").Add(options); // prototype.js var options = $R(1, 12, false).map(function(i) { return new Element("option", { value: i }).update(i + "月"); }); var elem = $("selectID"); options.each(function(e) { elem.insert(e) });
X.Elem()もAdd()もLinqオブジェクト/可変長配列を受け取れるので、まとめてドバーっと追加が結構楽かな、と思います。eachとかじゃなく、そのまんま追加出来るってのが大事。上の例だと、prototype.jsではmapでoptionsを作らずそのまんまeachでinsertしちゃえばいいぢゃん、というのはそのとーりなんですが(2回もループ回ることになるしね、あ、linq.jsのは遅延評価しているのでループはAddで呼び出される時の1回しか回りません)、配列(的なもの)が既にある状態ってのは、結構ありますよね?
と、何故か突然アピールしてますがlinq.xml.jsは作りかけで放置しているので足りない関数がいっぱいあるんですけどね!
WSH用にCOMのIntelliSenseを自動生成する
- C# JavaScript linq.js - 09.08/24
本題、の前にJavaScript用のIntelliSenseの作成方法について。以前、linq.jsにIntelliSense用ファイルを追加した時に利用法を書きましたが、今回はvsdocの作成方法を、ざっと書きます。まずVS2008 SP1とパッチを適用する。hoge.jsに対しhoge-vsdoc.jsを用意するとhoge.jsのかわりにhoge-vsdoc.jsがIntelliSense用に読み込まれる。IntelliSenseでVSが見ているのはメソッド名と引数だけなので、コードの中身はなくてもいい。例えば本来は存在するがprivateメソッドのつもりのものは、vsdoc.js側に書かなければIntelliSenseには表示されない。C#と同様に関数にはXMLドキュメントコメントを記述することが出来る。記述箇所はC#とは異なり開始の波括弧の直下。ドキュメントコメントのタグで現在機能しているものはsummary, params, returnsのみ。特に重要なのはreturns typeで、これにprototypeが存在する関数(ようするにクラスですなー)を指定することで戻り値の型をVSに認識させ、IntelliSenseを働かせることが出来る。ちなみに、ただのオブジェクトだと認識してくれない。
function Hoge(aaa, bbb) { /// <summary>hogehogehogehoge</summary> /// <param name="aaa" type="String">a!a!a!a!a!</param> /// <param name="bbb" type="Optional:Boolean">b?b?b?b?b?</param> /// <returns type="Number"></returns> }
基本はこんな感じ。引数の省略や、型が目で見て分かるので大分書きやすくなります。 で、いつぞやかに作成中とか言っていた通りにlinq.jsをWSH対応させようとしているわけですが、IntelliSense書きの量が思ったよりも膨大なわけです。実は最初は普通に手書きしてました。一応勉強も兼ねて書写みたいなノリで。ですが、あまりにも手間かかりすぎるので自動生成することにしました。こんなの人力でやるもんじゃないですよ。微調整はどちらにせよ必要なのですか、大枠だけでも書きだされていると物凄く楽になる。
static void Main(string[] args) { // add reference and replace dll path var assembly = Assembly.LoadFrom(@"Interop.IWshRuntimeLibrary.dll"); var types = assembly.GetTypes(); var enums = types .Where(t => t.IsEnum) .OrderBy(t => t.Name) .Select(t => string.Format("{0}: \r\n{{\r\n{1}\r\n}}", t.Name, Enum.GetNames(t).Select(s => string.Format("\t{0}: {1}", s, (int)Enum.Parse(t, s))).Join(",\r\n"))); var classes = types .Where(t => t.IsClass) .Select(type => { var bindingFlag = BindingFlags.Public | BindingFlags.Instance | BindingFlags.DeclaredOnly; var properties = type.GetProperties(bindingFlag) .OrderBy(pi => pi.Name) // .Select(pi => string.Format("{0}: {1}", pi.Name, pi.PropertyType.Name .Select(pi => string.Format("{0}: null", pi.Name)); var methods = type.GetMethods(bindingFlag) .Where(mi => !mi.IsSpecialName && mi.Name != "GetEnumerator") .Select(mi => new { mi.Name, Parameters = mi.GetParameters(), ReturnType = mi.ReturnType.Name }) .OrderBy(t => t.Name) .Select(t => string.Format("{0}: function({1})\r\n{{\r\n{2}\t/// <returns type=\"{3}\"></returns>\r\n}}", t.Name, t.Parameters.Select(pi => pi.Name).Join(", "), t.Parameters.Select(pi => string.Format("\t/// <param name=\"{0}\" type=\"{1}{2}\"></param>\r\n", pi.Name, (pi.IsOptional) ? "Optional:" : "", pi.ParameterType.Name.Replace("Void", "void").Replace("Int32", "Number"))) .Join(""), t.ReturnType.Replace("Void", "void").Replace("Int32", "Number"))); var result = properties.Concat(methods).Join(",\r\n"); return string.Format("{0} = function() {{ }}\r\n{0}.prototype =\r\n{{\r\n{1}\r\n}}", Regex.Replace(type.Name, "Class$", ""), result.Split(new string[] { "\r\n" }, StringSplitOptions.None).Select(s => "\t" + s).Join("\r\n")); }); var name = assembly.GetName().Name.Split('.').Last(); File.WriteAllText(name + "_enum.js", string.Format("{0}Enum =\r\n{{\r\n{1}\r\n}}", name, enums.Join(",\r\n").Split(new string[] { "\r\n" }, StringSplitOptions.None).Select(s => "\t" + s).Join("\r\n")), Encoding.UTF8); File.WriteAllText(name + "_class.js", classes.Join("\r\n\r\n"), Encoding.UTF8); } static string Join<T>(this IEnumerable<T> source, string separator) { var index = 0; return source.Aggregate(new StringBuilder(), (sb, o) => (index++ == 0) ? sb.Append(o) : sb.AppendFormat("{0}{1}", separator, o)) .ToString(); }
参照設定で対象のCOMを読み込んで、一旦ビルド。生成されてるInterop.hoge.dllを読み込んで解析、という流れをとってみました。もっとマシなやり方があれば教えてください。コードは、んーと、string.Formatがクドくて見難いですね! 最初はVSのフォーマッタに後で手動でかければいいや、と思ってたのを、出力状態でちゃんとフォーマットされてるようにと継ぎ接ぎしてたら酷いことに。一回文字列にしたものを改行でバラして再生成とか笑えない。こういうの、HTML/XMLが対象なら何も考えなくてもLinq to Xmlで綺麗に書けるのになあ……。 それ以外はまぁ、こんなものかしらんって感じでしょうか? リフレクションが絡むとLinq大活躍。Selectがネストしまくるのでクエリ構文の出番はない。リフレクションは掘り進める都合上、ネストが深くなるのでLinqがなかったら、と思うとゾッとします。最近はforの二重ループですらウエエ、とか思ってしまうので。
IWshRuntimeLibraryEnum = { IOMode: { ForReading: 1, ForWriting: 2, ForAppending: 8 } } Folder = function() { } Folder.prototype = { Name: null, ParentFolder: null, Drive: null, CreateTextFile: function(FileName, Overwrite, Unicode) { /// <param name="FileName" type="String"></param> /// <param name="Overwrite" type="Optional:Boolean"></param> /// <param name="Unicode" type="Optional:Boolean"></param> /// <returns type="TextStream"></returns> } }
一部抜粋ですが、こんなようなデータが出力されます。プロパティが全部nullなのは、ここに未指定のものが記述されているとIntelliSenseがエラー起こしてしまうから。例えばDrive: new Drive()で戻り値の型指定が可能といえば可能なのですが、出現位置の上下が問題になってくるので結構面倒くさい。ようはFolderよりも上にDriveがあれば関数が存在するので大丈夫だけど、下にあれば存在しないのでエラー。当たり前といえば当たり前なのですが、ダミーでのIntelliSense作りとしては面倒な問題でして。 この辺は素直に諦めて全部nullで型連鎖を止めてしまうのがお気楽といえばお気楽。あと、Dateはnew Date()にしてもDate.prototypeにしても型指定出来なかったりする問題もある。これは今のところ対処不能。
そんなわけで、linq.js + WSHはわりと順調に作成中なので期待しないでも待っててください。IntelliSenseというだけじゃなく、JScriptではバイト配列が扱いにくいので、扱いやすく出来るような補助メソッドを用意したりとか色々やってたらいつになっても終わらないー。例としてWSHでMD5を作る、とか。.NET Frameworkを通しているのでSHA1でも何でもいけます。これでWSHでwsse認証通してAtomAPIで投稿、とか出来ますね。まあ、もうC#でいいぢゃん、って気がかなりしなくもないですけど、うーん。C#4.0からdynamicが追加されるからCOM連携も楽になるしねえ。ただサイドバーガジェットに使うとか、JavaScriptの用途はまだまだあるもん!(これもSilverlightでやれば?って話がなくもないので、うーん)
linq.js :: Next
- JavaScript linq.js - 09.08/02
音沙汰のないlinq.jsなんですが、現在はWindows Script Host対応を進めています。対応といっても数カ所書き換えるだけなんですけど、それに合わせてWSH用のラッパーライブラリを書いているので、それに時間を取られてる感じです。基本的にはほんと薄いラッパーで、列挙処理がlinq.jsに渡せるのでそっちで好きに処理してね、という方向なので機能面での補助は一切なく別にすぐ出来上がるというかもうほとんど出来てるんですが、IntelliSenseを聞かせるためのvs-doc書きに物凄く時間喰われています。とにかくIntelliSense命な私は、IntelliSenseが動かないものなんて書きたくない!なければ自分でIntelliSenseを書く!という意味不明な方向で頑張ってます。
画像の一枚目は一週間前のものなので、現在はW.ToLinqは廃止して、E.Fromで動くようになってます。何のこっちゃ。
このご時世、WSHなんて下火、これからはPowerShellだよねー、って感じですが、それでも私はWSHで頑張る! WSHでLinq書けるのかゴルァ、を合い言葉に。JavaScript好きだし。まあ、素のJScriptだとEnumeratorを被せなきゃいけなくて列挙処理がゴミで使う気になれないのは確かなのですが、そこをlinq.jsがあれば何とか出来るわけなので、全然WSHは現役で行ける、Windows7時代でも全然行ける、と思います、思いたいです。まあ、あとWindowsサイドバーガジェット(デスクトップガジェット)にも使えるので、もうちっと踏ん張っていきたいな、というところ。Web系で頑張るのは無意味なのでニッチを狙いだしたとかそういうことではありま、す。
linq.js ver 1.3.0.2 - CascadeDepthFirst/BreadthFirst
- JavaScript linq.js - 09.06/15
linq.jsにCascadeDepthFirst, CascadeBreadthFirstを追加しました。ちょっと分かり辛いのですが非常に強力です。深さ優先/幅優先で多段SelectManyをかけていくようなイメージ。説明しづらいので例をどうぞ。
<div id="tree">Root <div>Spine <div>Neck <div>Head</div></div> <div>RClavicle <div>RUpperArm <div>RLowerArm <div>RHand</div></div></div></div> <div>LClavicle <div>LUpperArm <div>LLowerArm <div>Hand</div></div></div></div></div> <div>RHip <div>RUpperLeg <div>RLowerLeg <div>RFoot</div></div></div></div> <div>LHip <div>LUpperLeg <div>LLowerLeg <div>LFoot</div></div></div></div></div>
こんなHTML、というかツリーに色々と操作することにします。例えばinnerTextのように、深さ不明のchildNodesを全て掘ってTextNodeだけを取り出して値を連結するとしたら、通常は再帰を使いますよね。でも、CascadeDepthFirstを使えば
var root = document.getElementById("tree"); var innerText = E.Make(root) .CascadeDepthFirst("$.childNodes") .Where("$.nodeType == 3") .Select("$.nodeValue") .ToString();
こんな感じに書けます。rootから深さ優先探索で子ノードを全取得、そのうちnodeTypeが3のもの(TextNode)のnodeValueを文字列連結。宣言的に、再帰よりも分かりやすく書けます。何より後段で豊富なLinqメソッドを使って値を操作していけるのが利点になります。今回から新しく追加されたMake(hoge)というのはRepeat(hoge,1)と等しい。Fromを用いるとオブジェクトはKeyValuePairに、文字列は一文字ずつのシーケンスに化けてしまうので、今回からこのメソッドを用意しました。
実のところMakeもCascadeDepthFirstもC# 3.0 Supplemental Library: Achiral - NyaRuRuの日記のパクりです(AchiralではMakeはMake.Sequence)。ぶっちゃけ今までも勝手に散々パクッているので(ごめんなさい、ありがとうございます。ライセンス的にアレっぽいので、どこかに書いておかないと……) むしろ何で今更追加なのかというと、あまりにも露骨すぎて劣化コピーを入れるのは失礼に思っていて。結局入れてしまったけれど。そんなわけで応用的なものを一つ。引き続き↑のDOMツリーを使って……
var root = document.getElementById("tree"); E.From(root.childNodes) .Select(function(child) { return { child: child, parent: root} }) // 外部の値を取りこむ時は文字列ラムダ式は使えません .CascadeDepthFirst(function(pair) // 中を入れ子で親の値を参照したいので文字列ラムダ式は不可 { return E.From(pair.child.childNodes) .Select(function(child) { return { child: child, parent: pair.child} }); }, "v,n=>{value:v,nestLevel:n}") // CascadeDepth/BreadthFirstの第二引数はネストレベルを利用可能 .Where("$.value.child.nodeType == 1") // ELEMENT_NODEだけを取得するためフィルタ .WriteLine(function(t) { return t.nestLevel + ':' + E.From(t.value.child.childNodes).First().nodeValue + ' . ' + E.From(t.value.parent.childNodes).First().nodeValue; });
例もパクりです。与えられた木から,子→親への対応を作る,を C# で - NyaRuRuの日記を、HTMLだったらツリーはDOMだよね、という感じで書いてみました。第二引数にはネストレベルを取得できるリザルトセレクターが使えます(省略も当然可能)。んー、DOMだとTextNodeが混ざるせいで、例として不適切に処理が混沌としてしまいました。あ、WriteLineの部分は子要素のFirstがTextNodeであると決め打ちしてます。正確にやりたいなら冒頭のinnerTextの例のようにWhereでTextNodeのみに絞った上で、ToStringで連結したほうが良いですね。
CascadeDepthFirstをCascadeBreadthFirstに変えると(両者は探索方式が違うだけで引数や戻り値は一緒)、こんな結果になります。
動作の差異がよく分かるんじゃないかなーと思います。
continue/break
ForEachでcontinue/breakを使えるようにしました。
E.Range(1, 100).ForEach(function(i) { if (i % 2 == 0) return true; // continue if (i == 7) return false; // break alert(i); // 1,3,5 });
灯台下暗しというか、こういうのって自分が必要になるまで気付かないというか。Linqって基本的に前段階のWhereで絞るからこの辺のものって必要になる機会が少ないんですよね。いや、言い訳ですけど。で、まあ、jQueryと同じでtrueをreturnすればcontinue、falseをreturnすればbreakになります。実装は超単純。
while (enumerator.MoveNext()) { if (action(enumerator.Current, index++) === false) break; }
ActionなのにFuncになってしまった!しまった!と、思わなくもないけど、この辺が後付けでグダグダになるのはしょうがないので気にしないことにしよふ。じゃなくて、基本はActionなのでヨシとしておこう。むしろこの辺はJavaScriptがユルフワなのでC#ルールに(用語を)当てはめようとして無理が出ているだけ。そういえばで、個人的にはreturn;でcontinue、return true;でbreakにしたいなあ、とか思ったり思わなかったりなのだけど、その辺は標準に合わせた方が混乱しなくていいよねー、と思うことにしました。
Suggest(モドき)
- JavaScript linq.js - 09.06/10
どうも、新PC組んだりして(Core i7だしメモリ12GだしIntelのSSD2枚刺しでこれで数年は買い換えないでも前線で闘っていける!と思いたいのだけど、そこら中で微妙にコスト削減で若干残念になっていたり、ExtremeじゃなくてMainstreamなところとか) まあ、それはそれ。で、Windows7 RC1を入れて若干の苦戦を強いられていて環境整えるのに時間かかりそう-、というわけでショボいネタを一つ。
// これが補完候補、ただの文字列配列 var list = ["tokyo", "kanagawa", "tochigi", "saitama", "sapporo", "nagano"]; // イベントハンドラは引数を二つ取る、一つは送り元、もう一つはイベント X.ID("inputBox").AttachEvent("keyup", function(sender, event) { var suggestArea = X.ID("linqsuggest"); suggestArea.RemoveNodes(); // 子ノード全削除 if (event.keyCode == 13) // eventはイベント { sender.value = ""; // 空にするだけ…… return; } var text = sender.value; // senderは送信元DOM要素、今回はTextBox // この4行が本編です、ええ suggestArea.Add(X.Elem("tbody", E.From(list) .Where(function(s) { return s.indexOf(text) != -1; }) .Select(function(s) { return X.Elem("tr", X.Elem("td", s)) }) )); });
入力補完モドきです。見にくいですけど、ソースコードの上にある入力ボックスにgaでkanagawaとnaganoが表示される、とかそんな感じ。エンターキーによる入力には対応してません、ただたんに絞り込んで表示するだけのデモです。んーと、suggestArea.Addからの、たった4行でリストの絞り込みして->DOM作成が出来るね、簡単だね、素晴らしいね、関数型構築とLINQの合わせ技は強力ですよね、だからみんなも使ってね、ということが言いたいそうです。世の中、WhereしてSelectするだけで9割方カバー出来る。気がする。気のせい。
ちゃんと真面目に作っていきたい気もするのですが、この強引リニアサーチのまま拡張しても野暮ったいだけで意味ないなー、と思うので気が乗らない。でも、大量のデータを扱うわけじゃなければ、この程度の手抜き実装でも普通に何とかなるものですよねー、とは思わなくもない。無理に洗練されたものを作ろうとせず、領域を見極めて労力を最小限にしたいと私は思ふ。いや、手抜きじゃなくて。手抜きですけど。
今後のlinq.xml.jsは微妙に機能足りてないというか、クロスブラウザ回りがグダグダなのと(Attributeにstyle指定がIEだとコケるとか!) DOMと混ぜ合わせてると気になるところが幾らかあるので、ボチボチと作っていきます。素のlinq.jsには深さ優先探索/幅優先探索を入れようとしているのですが、PC入れ替え中なのでもうしばらく後。
一体誰にアピールしてるの?な寂しさを感じつつも、それを言ったら前回の記事なんてどこからどうみても露骨なまでに受け狙いに走ったわりには大不発で寒すぎたので、それを考えたらマシです、いや、よくわからないけれど。でも簡単アピールは何か違う気がする……。うーん。まあ、誰が使わなくても自分は使うわけなので適当に行きましょふ。
最もタメになる「初心者用言語」はVisualStudio(言語?)
- C# JavaScript linq.js - 09.06/06
本題、に入る前にlinq.jsの更新内容を。今回からVisualStudio上でJavaScriptを書く際にIntelliSense(コード補完)のサポートが効くようになりました。これでもうリファレンスと睨めっこしなくてもすみます。IntelliSenseが出てくれば使えて、出てこなければ使えない。引数の型までは補完してくれませんが、メソッドチェーンに関しては100%信頼出来ます。利用するにはVisualStudio2008 SP1と対応パッチをあてる必要があります。私はProfessionalで確認していますが、Express Editionでも行けると思います。
もう一つ、linq.xml.jsのほうは、今回からXML/DOMの関数型構築が可能になりました(関数型構築の詳細は前回記事を参照ください)。それに伴い実例として、同梱してあるTwitterビューアサンプルも関数型構築に、ついでに@usernameにアンカーを張るように変更しました。
DOM構築時にLinqクエリを埋め込めると何が便利なの?のサンプル。全体像(obj.textって何だよ、とか)は同梱のものを見てください。obj.textは「@hoge hugahuga @foo hogehoge」な感じ(ようはTwitterの投稿の本文)で、文字列置換なら@usernameをa hrefで囲むだけだけど、DOMでやるにはどうしよう→全部マッチさせちゃえばいいぢゃない、それならSelectで射影すると楽ですね、という流れ。E.Matchesはキャプチャ付きの正規表現グローバルマッチが気楽に使えて非常に便利。
VisualStudioの薦め
以前に最もタメになる「初心者用言語」は、という話題で盛り上がっていたけれど、その時JavaScriptを挙げた人の多くが開発環境を入れる必要なく、テキストエディタがあればそれだけで始められるから、といったものが多かったけど、正直どうかなー、と思っていました。1年以上前のネタに今頃乗っかるのって感じですが今頃乗っかてみます。
初心者は、使えるメソッドが分からないから一々リファレンスを引くのに手間取るし(私は今だって文字列のsubstrとsubstringで悩む、特にJavaScriptはこの手の罠が多いし)、しょうもないタイプミス(大文字小文字とか)に悩まされてプログラムが動かない。演算子やカッコにスペースを空ければいいのかどうかも悩むし、一々手で直すのは手間だけど直さなければ汚いし……。
言語の学習って、特に最初はとにかく書くこと、それが最も覚えやすいと思うのです。リファレンスを引く時間も、手動でスペースを空ける時間も、言語の学習とは全く関係ない余計な時間です。限りなくゼロに近づけた方が良い。リファレンスを引く時間がゼロならば、その分だけ書く作業に時間を回せます。だから、テキストエディタじゃなくIDEを使おう。入力補完は一々リファレンスを引く必要もなく使えるメソッドをリストアップしてくれるし、ヘルプを見る必要もなくメソッドの解説が書かれている。補完があるからタイプミスも起こらないし、「長くてもいいから良い名前を付ける」習慣もつく。インデントだのスペースだのカッコの段落だのは、全てドキュメントフォーマッタ(VSではCtrl+E,D)で機械に任せるのが、完璧で綺麗で、何より手間がかからない。
そんなことより前に、そもそもforで変数がどう移り変わっているのかもよくわからないし。デバッガ、あったほうがいいでしょう、絶対に。あるのとないのとでは学習速度の桁が違ってくる。Firebugがあるって?いや、Firebugは確認用には物凄く便利だけど、それの上で開発とか辛くない?私は無理でした。ついでに言えば、Firebugインストールする手間もVisualStudioをインストールする手間も一緒。
Microsoft Visual StudioはWebインストールを選べば何の手間もいらずダウンロードされ、そのままインストールに入り30分程度で終わる(ダイアログの「はい」を押して待つすだけです、Eclipseと違って何入れればいいか、プラグインがどうのこうの、で悩む必要なくそのものがAll in One)、VSの使い方を知るのに30分。周囲に使える人がいれば、勘所を聞くだけで済むので10分。別に何も最初から全てを知る必要はなく、ダミーのASP.NETプロジェクト作って、F9でブレークポイント設定してF5でデバッグ実行してウォッチウィンドウで変数を監視する。それだけ分かれば十二分です(そこを分かるまでが辛い、というのはあります、分かっている人が横にいれば1分で済む話なのに、こんな初歩的な情報はあまりネットに転がってないから分かりようがない。需要がありそうなら書きますが……)
jQueryにも使える
jQuery大人気! やっぱjQueryが使えないとね!と、で、VisualStudioはjQueryに、jQueryオフィシャルが対応しています。どういうことか、というとjQueryのダウンロードページを見てください。Release NoetsとMinifiedとUncompressedと、Documentation: Visual Studio。そう、この公式に配布されているjquery-vsdoc.jsを使う(jquery.jsと同じディレクトリに置くだけです)と、VS上で丁寧に書かれた解説付きの入力補完が効くようになります。
jQueryの特徴といったらメソッドチェーン。ドット打つとの候補が出てくる出てくる、という感覚はとても楽しい。その楽しさを更に加速させるのがIntelliSense。メソッド名何だっけ、引数は何を取るんだっけ、と悩むこともない。ドット打って選ぶだけ。処理の本質部分だけに集中できる。
そういえばオブジェクトっぽい話が分かるかもしれないJavaScript講座が大人気ですけれど、便乗して言うとjQuery使うなら、まずVisual Studio、があれば、もうあとはドット打つだけなので何も考えないでもいいぐらい。んーと、本題はオブジェクトっぽい話、ですけれど、アレですね、何のかんのでオライリーのJavaScript 第5版を読むのが一番分かりやすかった。ケチッてWeb上のチュートリアルをブクマして読んで、なんてやるよりも、この場合は黙って金出して本読むのが時間の節約にも、得られる知識の濃さ的にもよろしいかと思われます。
amazonついでにLINQ本も張っておきます。LINQ本は以前に「LINQテクノロジ入門」という薄い本が出ているのですが、ほとんどLinq to Sqlのことしか書いていないので、少し高いのですが本で学ぶのならこちらの、プログラミングLINQのほうが良いです。初級-中級的にはLinq in Action
のほうがお薦めなのですが翻訳されてないしされる気配もなさそうですね、残念。そうそう、linq.jsも宜しくお願いします。
C#との高い互換性と、リファレンスにおいてあるLINQ Padはリアルタイムに動作を確認可能、なので学習用途ならかなりイイと思います。パフォーマンスは?実装がヘコい?是非とも突っ込みを!
入力補完の嬉しさ
まんじゅうの例を借りると、prototypeにメソッド突っ込んでオブジェクトほにゃららで何が嬉しいのか、というと、入力補完が効く。使えるメソッドがドット打つだけで出てくるし手入力する必要ない。jQueryのようにヘルプは出てきませんが、補完はちゃんと効くのです。同様に何のメソッドがあるのかさっぱり分からないDOM要素に対しても動くし、紛らわしさ全開な文字列に対しても効きます、便利便利。こうして眺めてると、知らないメソッドがあったりして勉強にもなる。
ところで突然C#の話に移って同様に、ポリモーフィズムで何が嬉しいの→入力補完が効く。ジェネリクスの何が嬉しいの→入力補完が効く。動的言語じゃなくて静型な型付け言語(C#とかJavaとか)の何が嬉しいの?→入力補完が超完璧に効く。型推論の何が嬉しいの?→入力補完が超完璧に効く上に更に型を入力する手間も最小限に抑えられる。
// これをそれぞれ二乗する int[] array = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; // C# 2.0ではこんなクソみたいなコードが int[] c2 = Array.ConvertAll<int, int>(array, delegate(int i) { return i * i; }); // C# 3.0ではこんなに短く! Rubyっぽく見えませんか? var c3 = array.Select(i => i * i);
C#2.0だと、本質的な記述部分(i x i)以外の量の方が死ぬほど多くなってしまい、これじゃ嫌われて然りであり動的言語に行きたくもなる。何個intを書かせるんだよボケ、intなんて自明なんだよクソがって感じです。けれど、C#3.0からの型推論+ラムダ式があればとてもすっきりした上に、ちゃんと補完が効く(i x iを記述している最中もiがintであることを示してくれる)ので物凄く書きやすい。JavaScriptもいいけどC#も良いです。無名関数を愛するJavaScripterならC#のラムダ式はもっと愛せると思います(ウザいカッコとreturnが必要ないので)
C#は特にWindows用のデスクトップアプリケーションを作るなら、作りやすさで言えばベスト。.NET Frameworkは嫌だ?やっぱC++でしょって?うーん、ゲームを作るんでもないならC++の性能は必要ないし、作りやすさでいったらC#>超えられない壁>C++ですよ。C#は開発者に優しいゆるふわ言語。C++はF1マシン、とっても扱いにくいけど凄く速い。C#はプリウス。実用性と最先端ハイテクのバランスが絶妙。そもそも公道をF1カーで走ることが無茶苦茶なのです、公道はプリウスで十分どころか、むしろベストというもの。何にでも、適した領域というものがある。
しかも今C#を覚えると、もれなくSilverlightも付いてきます(Flashの開発言語がActionScriptであるように、Silverlightの主な開発言語はC#)。Flashに勝てるわけないだろヴァーカって?何にせよとりあえずツバだけでもつけておくと生きやすいかなーって思いません?Flash業界なんてレッドオーシャンもいいとこ、今から飛び込むならSilverlight。Microsoftは本気なのであっさりと消滅することはないでしょう。本気の時のMicrosoftはとってもしぶとくしつこい。
でもまあ、そんな云々はどうでもよくて、普通にLINQ楽しいですよ!が一番に言いたいことです。ええ、LINQ楽しい。LINQがあるからC#万歳だし、LINQがなくても作ったのでJavaScriptも万歳。linq.jsは初回リリース時にチュートリアルめいたものが書いてあるので、よければどうぞ、というかお願いしますお願いします。
DOMの関数型構築
- JavaScript linq.js - 09.05/29
Linq to XMLのJavaScript移植、もポチポチと進めています。
var xml = new XElement("customer", new XAttribute("id", "c001"), new XElement("firstName", "Paolo"), new XElement("lastName", "Pialorsi"), new XElement("addresses", new XElement("address", new XAttribute("type", "email"), "paolo@devleap.it"), new XElement("address", new XAttribute("type", "url"), "http://www.devleap.it/"), new XElement("address", new XAttribute("type", "home"), "Brescia - Italy") ) ); alert(xml.Source.outerHTML); // .Sourceは気にしないでください(最終的には隠蔽されるので)
これは何と、C#にコピペしても動く。つまり互換性100%(笑) 所謂マークアップビルダになります。私がC#っ子だから、というのもあるけれど、JSON風に書くより好き。JSON風だとそれぞれのライブラリが属性対応のため変則的な書き方ルールが用いられていて、それを覚えなきゃいけないけれど、これなら要素に属性と値を突っ込むだけなので学習コストがほとんどない。と、思う。IntelliSenseのサポートも効くし(現在linq.jsをIntelliSenseが効くよう整備中です、土日に書きすすめて公開、したいなあ)。そのかわりnewだらけでちょっと冗長に過ぎるところはあるかもしれない。
// ユーザー名と発言と投稿を持ったクラス var Twit = function(user, text) { this.user = user; this.text = text; } // とりあえずサンプルデータ var data1 = new Twit("ika", "いかはいかが"); var data2 = new Twit("tako", "たこやき"); var data3 = new Twit("sakana", "丸焼き"); // XmlHttpほげほげだのJSONだのな結果の例として配列 var list = [data1, data2, data3]; // リストをSelectでXElementに射影すると自動的に展開される var xml = new XElement("twitter", new XElement("account", "neuecc"), new XElement("twits", E.From(list).Select(function(t) { return new XElement("twit", new XAttribute("user", t.user), t.text) })) ); alert(xml.Source.outerHTML); // .Sourceは気にしないでください(最終的には隠蔽されるので)
例をもう一つ。例が適当かつ分かり辛くてすみませんなのですが、Selectで射影しておくと、展開されます。何らかのオブジェクトを繰り返してDOMにする、というシーンは多いと思うのですが、forはもう必要ありません。むしろfor禁止。ループは悪。「この配列を」「この形に展開する」と宣言的に記述するだけで良いのです。
var table = new XElement("table", new XElement("tr", new XElement("td", "column1"), new XElement("td", "column2"), new XElement("td", "column3") ), E.Repeat("tr", 5).Select(function(tagName) { return new XElement(tagName, E.Range(1, 3).Select(function(i) { return new XElement("td", new XAttribute("style", (i % 2 == 0) ? "background:red" : "background:green"), "row" + i); }) ) }) ); // FirefoxではouterHTML動きませんけど、最終的には隠蔽されるので(ry document.body.innerHTML = table.Source.outerHTML;
簡単なTableの生成例。これrowになってませんね、あはは。まあ、いいや。関数の引数の中に式を書くという感覚が最初はキモかったのですが、今では平然と書くようになってしまいました。何というLinq中毒……。しかし、JavaScriptだとfunction(){return }のせいでゴチャゴチャして分かり難いものになってしまう。ラムダ式欲しいなあ。{とかreturnとかいらない。Firefox3では省略出来るけど、Chromeはまだ出来ないみたい……。
Firefox3は使えば使うほど嫌いになるという素敵ブラウザなので、本気でChromeに乗り換える気はありますよ!アドオンがなければ自分で作ればいいじゃない、と思うことにしますので、作りたいですね。一応Hello,Worldは書いた。
<script type="text/javascript" src="linq.js"></script> <script type="text/javascript" src="linq.xml.js"></script> <script type="text/javascript"> // Initialize X.Initialize(function() { X.ID("panel").AttachEvent("click", panel_onclick); }); // EventHandler function panel_onclick(sender, event) { X.ID("titleLabel").SetValue(event.screenX); } </script> <div id="panel" class="toolstrip-button"> <span id="titleLabel">Hello, World!</span> </div>
ええ、ただのHTMLです。ステータスバーのところにHello,Worldが出てクリックできるという、それだけのもの。Chromeの拡張はまだ何が出来るか分からないというか何も出来ないというか、それグリモンでいいよね、的なことしか出来ない感じなので、その間、今のうちにlinq.xml.jsを完成させよう。何かもう意地でも自分は使う、な方向に傾いてる気がしますが。jQuery?何それ。
JavaScriptで総当たり
- JavaScript linq.js - 09.05/27
Baker, Cooper, Fletcher, MillerとSmithは五階建てアパートの異なる階に住んでいる。Bakerは最上階に住むのではない。Cooperは最下階に住むのではない。Fletcherは最上階にも最下階にも住むのではない。MillerはCooperより上の階に住んでいる。SmithはFletcherの隣の階に住むのではない。FletcherはCooperの隣の階に住むのではない。それぞれはどの階に住んでいるか。
// 条件を並べて総当たり問題を解く var apart = E.Range(1, 5); var answers = apart .SelectMany(function(baker){ return apart .SelectMany(function(cooper){ return apart .SelectMany(function(fletcher){ return apart .SelectMany(function(miller){ return apart .Select(function(smith){ return { baker: baker, cooper: cooper, fletcher: fletcher, miller: miller, smith: smith}})})})})}) .Where("E.From($).Distinct('$.Value').Count() == 5") .Where("$.baker != 5") .Where("$.cooper != 1") .Where("$.fletcher != 1 && $.fletcher != 5") .Where("$.miller > $.cooper") .Where("Math.abs($.smith - $.fletcher) != 1") .Where("Math.abs($.fletcher - $.cooper) != 1"); // 動作確認、Templateのお陰で記述がとても楽 answers.ForEach(function(obj) { var str = Linq.Tools.Template("baker : {baker},\ cooper :{cooper},\ fletcher :{fletcher},\ miller : {miller},\ smith : {smith}", obj); alert(str); // とりあえずalertで確認 });
メソッド構文の最大の敵、多重fromを何とかする。今回の場合はカッコを閉じず、最後にSelectを使えばクエリ構文に近い見た目が確保できる。大量の閉じ括弧と、大量のWhereに対してラムダ式が面倒くさくなるのだけはどうにもならないのだけれど。C#で一通り書いてから、JavaScript + linq.jsに書き直したのが上記のもの。C#のは載せませんけれど、ほとんど一緒です。
Distinctの部分だけはlinq.jsのほうがC#より書きやすい。匿名型を突っ込んでもハッシュなので、そのままセレクター渡して比較出来ちゃうので。あとWhereラッシュに対して$がGroovyのitのようなデフォルトのイテレータ引数として機能するので記述が楽なのは利点といえば利点。itのようなものはC#でも欲しいなあ、と思ってたりはする。
パフォーマンス?気にしたら負け、かな……。Chromeなら十分な速度で動くし。理想ではJavaScriptな人にもC#やLINQの良さが伝えられればな!なわけなのですが、現実は非常に厳しく誰もDLしてないよねですよね的ではあるけれど。うーん。
まあ、とりあえず、JavaScript的に特異なコードが書けるのでお遊びにでも使ってもらえると嬉しいです。
linq.js ver 1.3.0.0 - Unfold, Matches, etc…
- C# JavaScript linq.js - 09.05/24
今回は本体も含めて大量更新です。生成子にUnfoldとMatchesを追加しました。Unfoldは応用範囲がとても広く(広すぎて逆に使い道が思いつかない)、Matchesは正規表現がより使いやすくなるので、実用度が非常に高いと思われます。そして、FromにStringを入れたときの動作を一文字毎に分解するよう変更。更に操作用メソッドにも、Insert, IndexOf, LastIndexOfを追加しました。あと、その他色々。
Unfold
UnfoldはAggregateの反対、といっても良くわからないのですが、引数と戻り値の型が同一の関数を無限に適用し続ける、という感じです。例えばE.Unfold(0, “$+3″)は、初期値が0で、適用する関数が+3。というわけで、0,3,6,9….と無限に3ずつ増幅していく値が取り出せます。これだけでは終了しないので、終了条件はTakeかTakeWhileで別に与えます。
// フィボナッチ数列の無限リスト var fib = E.Unfold({ a: 1, b: 1 }, "{a:$.b, b:$.a + $.b}").Select("$.a"); // 10個分だけ画面に出力 - 1,1,2,3,5,8,13,21,34,55 fib.Take(10).WriteLine(); // abcdefを一文字ずつ削っていく- abcdef,bcdef,cdef,def,ef,f E.Unfold("abcdef", "$.substr(1)").TakeWhile("$.length>0").WriteLine();
例はフィボナッチ数列で、これは熟練した C# 使いは再帰を書かない? - NyaRuRuの日記の丸コピです。タプルの片方を計算用の一時領域として使う、という感じでしょうか?
static void Main(string[] args) { // 16進の文字列をByte配列に変換する var str16 = "FF-04-F2 B3 05 16F3"; var regex = new Regex(@"[abcdef\d]{2}", RegexOptions.IgnoreCase); // 全部マッチさせてから変換 var byteArray1 = regex.Matches(str16) .Cast<Match>() .Select(m => Convert.ToByte(m.Value, 16)); // Unfold使って一つずつ変換 var byteArray2 = Unfold(regex.Match(str16), m => m.NextMatch()) .TakeWhile(m => m.Success) .Select(m => Convert.ToByte(m.Value, 16)); } static IEnumerable<T> Unfold<T>(T seed, Func<T, T> func) { while (true) { yield return seed; seed = func(seed); } }
UnfoldをC#で正規表現のマッチに使ってみた。あまり意味はない。これをJavaScriptでやると、マッチオブジェクトにNextMatch()がないので、lastIndexの変化したRegExpにexec()し続ける必要がある。というわけで、Timesを使えば同じことができます。E.Times(”regex.exec(input)”).TakeWhile(”$ != null”) です。String.match(オプションはglobal)を使って配列を取得したほうが楽なのですが、それだと文字列配列(みたいな何か)であって、個々のマッチオブジェクトが取れないので、個々のindex(一致した位置)やキャプチャが必要な場合はRegExp.execを使う、という使い分けかなー、と私は思っています。
Matches
そんなことを考えていたら、やっぱRegExp.execのglobalって使いづらいね、と思ったのでE.Matchesを追加しました。C#のRegex.Matchesと同じようにマッチオブジェクト全てを返します。配列で欲しい場合はToArray()を。そのまま処理を加えたい場合は、Linqのメソッド群全てが使えます。マッチのうち先頭だけが欲しいけど射影処理もしたい場合はMatches().Select().First()という手が使えます。
var input = "abcdefgABzDefabgdg"; E.Matches(input, "ab(.)d", "i").ForEach(function(match) { for (var prop in match) { document.write(prop + " : " + match[prop] + "<br />"); } document.write("toString() : " + match.toString() + "<br />"); document.write("<br />"); }); E.Matches(input, /ab(.)/i); // こうも書ける、gフラグはつけなくていい E.Matches(input, "ab(.)d"); // 大文字小文字を区別するならflag無しで
E.Matches(input, pattern, flags)で、patternは文字列でも正規表現オブジェクトでも、どちらでも可能。flagsは省略可、与える場合は仕様通り”i”, “m”, “im”が使えます。gフラグを明示的に与える必要はありません。与えても与えなくても関係なくglobalで検索します。
中に入るマッチオブジェクトなのですが、[0]にマッチした文字列全体、キャプチャがある場合は[1]以降にキャプチャした文字列が入ります。あとは.indexと.input。IEだと.lastIndexも取れてますが、IE以外のブラウザではlastIndexは使えません(undefinedでした)
From(String)
今までE.From(”hoge”).ToArray()とすると[0]=”hoge”になっていました。つまりE.Repeat(”hoge”,1)というわけです。これは、何というか、意味ないですよね。C#だと[’h',’o',’g',’e']というように、Charに分解します。というわけで、E.From(”hoge”).ToArray()の結果が[”h”,”o”,”g”,”e”]になるように動作を変更しました。
var input = "こんにちは みなさん おげんき ですか? わたしは げんき です。\ この ぶんしょう は いぎりすの ケンブリッジ だいがく の けんきゅう の けっか\ いかりゃく" var result = E.From(input.split(/[\s\t\n]/)) .Select(function(s) { return (s.length > 3) ? s.charAt(0) + E.From(s).Skip(1).Take(s.length - 2).Shuffle().ToString() + s.charAt(s.length - 1) : s; }) .ToString(" "); alert(result);
サンプルとして、流行から100歩遅れてケブンッリジ変換をlinq.jsで。
真ん中の、「E.From(s).Skip(1).Take(s.length - 2).Shuffle().ToString()」という部分が「こんにちは」を「こんちには」に変換する部分です。E.From(s)で文字列を一文字ずつにバラしているわけです。Skip(1).Take(s.length-2)が、「最初と最後の文字を除く」です。実際の実行例は下のURLからどうぞ。
↑で動かしているものは、必ずシャッフルされるようにしたり、「、。!?」が末尾の時には別の処理をしていたりと、例に出しているコードとはちょっと違いますけれど。詳しくはソースを見てください。
その他
他に追加したメソッドはぶっちゃけ全然使い道ないのでササッと書き流します。まずInsertですが、これはConcatの場所自由版という感じにシーケンスを特定場所に挿入。IndexOf, LastIndexOfは位置の発見で見つからない場合は-1を返すというお馴染みな動作をします。他にlinq.tools.jsにHashSetを追加しました。これはC#のHashSetに似たようなもので、詳しくはリファレンス見てください。そして、Stopwatchに静的メソッドBenchを追加。これは、どうせStopwatch使うのはベンチマークの時だけでしょ?ということで。
var result = Linq.Tools.Stopwatch.Bench(1000, function() { E.Range(1,100).Where("$%2==0").Select("$*$").Force(); }); document.write(result + 'ms')
第一引数に繰り返し回数、第二引数に実行する関数。わざわざDateの引き算をすることなく、気楽に計れるので、便利といえば便利。というか、この手のものは手間がかかるとついつい避けてしまうので、サクッと計れないとダメですものね。
Stopwatch
- JavaScript linq.js - 09.05/18
昨日の今日で変更というのも申し訳ないのですが、メソッド名を変えました。DateFormatはDateUtility.Format、DateParseはDateUtility.Parseになります。すみません。それだけじゃアレなので、その月の日数を返すDateUtility.DaysInMonthと、うるう年かどうかを判定するDateUtility.IsLeapYearを追加。それと、ストップウォッチクラス。
// Stopwatchを生成・開始して…… var sw = Stopwatch.StartNew(); // 重たい処理をしたりして E.Range(1, 10000).Select("$*$").Force(); // Elapsed()でms単位で表示 alert(sw.Elapsed() + "ms"); /* その他のメソッド */ var sw = Stopwatch.Create(); // Stopwatchの生成(開始はしない) sw.Start(); // 開始/再開 sw.Stop(); // タイマー停止 sw.Reset(); // タイマー停止+経過時間リセット sw.IsRunning(); // 動いてるか止まってるか
そろそろ変数名とかインデントは、郷に入り手は郷に従うべきですよねー。ていうか、単純にJavaScriptでC#的な書き方を持ちだすと普通に宜しくない。特に、コンストラクタとメソッドを区別するために大文字小文字にする必要性はとても感じる。と言いつつも、懲りづに続けていたりいなかったり。
それにしても本体を更新していないのにバージョン番号が増殖していくのはどうかと思う。しかも今回のStopwatchとDateTime系のはlinq全く関係ないという有様。
linq.tools.js
- JavaScript linq.js - 09.05/16
更新しました。今回は本体じゃなくて、ユーティリティスクリプトの追加が更新内容になります。少し便利なあると嬉しいちょっとした関数群をlinq.jsを使って。つまりそれってようするにただのサンプル……とは言ってはいけません。実際問題、sampleフォルダに入れちゃってますけどね!
中身は前回のテンプレート置換、配列を使って文字列を追加するStringBuilder、HTMLタグのエスケープをするHtmlEncode/Decode、クエリストリングをオブジェクトに変換するParseQueryStringとオブジェクトをクエリストリングに変換するToQueryString、そして書式を利用してDateを文字列に変換するDateFormatと文字列からDateに変換するDateParse。
詳しくは同梱のリファレンスを参照してください。それだけでもアレなので中身を幾つか。
Linq.Tools.HttpUtility.ParseQueryString = function(query) { return E.From(query.split('?')) .SelectMany("$.split('&')", "a,b=>b.split('=')") .Where("$.length == 2") .ToObject("decodeURIComponent($[0])", "decodeURIComponent($[1])"); }
と、こんな感じでLinqを活用しています。?でバラして&でバラして=でバラしてオブジェクトに変換、と、QueryStringを見てまんま、思考のまんまに記述出来ます。便利便利。こういうのは個人的にもうforで書きたくないのですが、どうでしょう。
DateFormat / DateParse
Linq.Tools.DateFormat(date, format)はその名の通り、書式に基づいて日付を文字列に変換します。このぐらい標準で用意してあるといいのになあ……。formatは大体C#のに従う感じで、それなりに豊富。曜日も出せます。
Linq.Tools.DateFormat = function(date, format) { // 変数準備部省略 var PadZero = function(str, width) { var count = width - str.length; return E.Repeat("0", count).ToString() + str; }; var formatDict = { yyyy: year, yy: year.substring(2), y: year.substring(3), MM: PadZero(month, 2), M: month, dd: PadZero(day, 2), d: day, // 以下略 }; var regex = new RegExp(E.From(formatDict).Select("$.Key").ToString("|"), "g"); return format.replace(regex, function(m) { return formatDict[m] }); }
変数部分がダラダラ長いので省略してます。0埋め関数が地味にLINQ。で、中身はいつものマンネリな手口です。置換用辞書作って、キー抜き出して正規表現作って、置換する。というだけです。実質二行。辞書の持ち方が若干富豪ですが、この程度なら全然気にならないでしょふ。あ、正規表現はこれだと順序が大事なので(yyyyの前にyyがマッチングされては困る)オブジェクトのキーを並べるやり方だと少し不安だけど、まあ、大丈夫でしょう!辞書の中身が動かないのだから、別に動的生成する必要は全くないどころか百害あって一理無しなのですが、それもまあ、無視黙殺。
var day = Linq.Tools.DateParse("2009-11-12 131034", "yyyy-MM-dd hhmmss"); var str = Linq.Tools.DateFormat(day, "yyyy/MM/dd HH:mm:ss");
FormatがあったらParseもセットだよね、ということでParseも作りました。更に手抜きで、桁数が揃っていないと変換出来ません。だから使えるのはyyyy|MM|dd|HH|mm|ssだけです。hhはダメです。紛らわしくてすみません。あと、動作はyyyyとかのフォーマット文字しか見てないので、それ以外は何だっていいです。_でも空白でも、文字数だけ合わせれば動きます。とても適当。ソースも実にスッカスカ。
JavaScriptで文字列テンプレート
- JavaScript linq.js - 09.05/14
以前のString.Formatモドきが散々だったので、今回はもっとマトモに真面目にlinq.jsを使って書きます。
// {}で囲まれたものを置換する var template = "食べ物は{food}で{dummy}飲み物は{drink}らしい。"; // このオブジェクトに対応したものに置換、という簡易テンプレート var dict = { food: "タコ焼き", drink: "コーラ" }; // 目標とする結果は「食べ物はタコ焼きで{dummy}飲み物はコーラらしい。」 // dummyが引っかかってしまうのでダメ var text = template.replace(/\{(.+?)\}/g, function(m, c) { return dict[c] });
普通に横着して.+?で置換しようとすると、{dummy}もマッチしてしまって宜しくない。別にひっかかってもいいじゃん、オブジェクトで指定しているのしか{}で囲まないよ!とばかりも言ってられないシチュエーションは、それなりにある、と、思う。というわけでちゃんとオブジェクトのキーだけを抜き取って正規表現を生成する。
// テンプレートに使うキーだけを抜き取る var key = E.From(dict).Select("$.Key").ToString("|"); // food|drink var regex = new RegExp("\{(" + key + ")\}", "g"); var text = template.replace(regex, function(m, c) { return dict[c] });
linq.jsならSelectしてToStringするだけで出来あがる。と、いうわけで簡単です。ついでなので汎用的な関数にしてみる。区切りは決め打ちで{}です。気に入らなければ%%でも${}でも好きに変更してください。
// テンプレートで置換・区切り文字はとりあえず{} function templateReplace(template, replacement) { var key = E.From(replacement).Select("$.Key").ToString("|"); var regex = new RegExp("\{(" + key + ")\}", "g"); return template.replace(regex, function(m, c) { return replacement[c] }); } var template = "食べ物は{food}で{dummy}飲み物は{drink}らしい。"; var text = templateReplace(template, { food: "タコ焼き", drink: "コーラ" });
しかし毎回オブジェクトを作るってのも面倒くさい。順番決め打ちで気楽に置換したい時って沢山あると思う。というわけで、オブジェクト以外を渡した時はC#のstring.Formatと同じ動作をするように変更。typeofとかinstanceofとか、JavaScriptって面倒くさいよね。
// replacementがオブジェクトでない場合は可変長引数として動かす function templateReplace(template, replacement /* args */) { var key; if (typeof replacement != "object") { key = E.Range(0, arguments.length - 1).ToString("|"); replacement = E.From(arguments).Skip(1).ToArray(); } else if (replacement instanceof Array) { key = E.Range(0, replacement.length).ToString("|"); } else { key = E.From(replacement).Select("$.Key").ToString("|"); } var regex = new RegExp("\{(" + key + ")\}", "g"); return template.replace(regex, function(m, c) { return replacement[c] }); } // 名前をつけてObjectを渡す形式でも var template = "食べ物は{food}で{dummy}飲み物は{drink}らしい。"; var text = templateReplace(template, { food: "タコ焼き", drink: "コーラ" }); // 数字で指定する形式でも、どちらでも動く var template = "食べ物は{0}で{dummy}飲み物は{1}らしい。"; var text = templateReplace(template, "タコ焼き", "コーラ"); var array = ["タコ焼き", "コーラ"] var text = templateReplace(template, array); // 配列で渡しても平気
argumentsをFrom.Skip.ToArrayと、サクサクーとメソッド繋げて変換出来るので楽ちん。
C#でも大体同じ感じで書けます。ToStringは、String.Joinで代用可能。置換部分は、Regex.Replace(template, “正規表現”, m => replacement[m.Groups[1].Value]);ですね。replacementはDictionary<string, string>で。ラムダ式が便利なので、MatchEvaluatorがようやくホイホイ使えて、JavaScript並みに気楽に正規表現を書けるようになりました。
と、いうことで
試してみてくれるとかDisってくれるとか、はてブしてくれるとか紹介してくれるとか切望中。
無限日曜・ベンチマーク
- JavaScript linq.js - 09.05/08
var DayOfWeek = { Sunday: 0, Monday: 1, Tuesday: 2, Wednesday: 3, Thursday: 4, Friday: 5, Saturday: 6 } var today = new Date(); var sundays = E.ToInfinity() .Select(function(i) { return new Date(today.getFullYear(), today.getMonth(), today.getDate() + i) }) .Where(function(d) { return d.getDay() == DayOfWeek.Sunday });
今日以降の日曜日を無限に羅列。どうも日付話はLinqネタでよくあるらしいので、今更に。大量の使い捨てDateが気持ち悪いですが、ケチケチしちゃあいけません。これが富豪的プログラミング!?(何か違う気がする) ちなみに一年間なら、最後に.TakeWhile(function(d) { return d < 一年後 })とでもすれば良いわけです。無限万歳。
ベンチマーク
さて、linq.jsは遅い遅い連呼しているわけですが、じゃあ実際どのぐらい遅いのでしょうか。JSEnumeratorのベンチマークを拝借してテストしてみました。
ブラウザによって結構変わるようです。IEが爆遅でChromeが爆速なのは変わらないのですが、順位がわりと入れ替わっています。ていうかそもそも計る度に変動が激しいような……。linq.jsは、ForEachが若干遅いのが気がかりですが、LinqではForEachよりも(そもそもC#のLinqにはForEachが無い)mapとfilter中心なわけで、reduceがかなり健闘しているから問題ないと言えるのではないでしょうか? と、言いたいところなのだけどmapが遅いですね。一番よく使うmapが遅いですね。ふむ。
結論:Chrome速すぎ。Chromeの速度からすれば全て誤差範囲内に収まってしまうわけなので、じゃんじゃん使っていいと思うよ!ていうか、私としては思ってたよりも遅くなかった、が感想です。
linq.js ver 1.2.0.1 - 少しメソッド追加
- JavaScript linq.js - 09.05/07
ちょっとした、前から足そうと思ってた機能を追加しました。面倒くさくて放置していたのですが、ゴールデンウィーク何もしませんでした記念に追加しました。何もしなかったというか、今更ながらLeft 4 Deadを買って(Xブレードは勿論スルー)、それが面白いの何のでほんと連休はゲームしかしてなかったような。オラタンは操作に馴染めないなあ、とか思ってたんですが段々と感覚を取り戻せたみたいで(まあ、DC版しかプレイしてないんですけどね、回線利用料で月数万吹っ飛んだとか、今考えると泣けます) 当分は楽しめそうです。スペースインベーダーエクストリームは、これから考える。
Times
Repeat(null,10)という書き方をしてforの代用をしていたわけですが、非常にダサかった。ので、それと同効果のメソッドを用意しました。
E.Times("Math.random()", 10) // 10回ランダムを送出 E.Times(function() { return Math.random() }, 10) // 上のはこれの略記方です E.Times(function() { alert("Hello") }, 5).Force() // 5回Helloはこんな風で、Rubyっぽく?
例によって例はランダムで。まあ、こんな感じに使うと便利かなー、と思います。回数を省くと無限リピートになります。ようするに関数版Repeatなわけです。回数指定は後よりも前のほうがいいよねえ、とか思いつつも、Repeatと同じ感じにしたいというか、すべき(混乱するので、なるべくこういうのは統一したいです)だと思ったので、そんなわけでして。
step
MATLABやHaskellや、なんかにもあるのですが、増減値に1以外の任意の数が選べます。
E.Range(1, 9, 3); // 1,4,7,10,13,16,19,22,25 E.RangeDown(1, 9, 3); // 1,-2,-5,-8,-11,-14,-17,-20,-23 E.RangeTo(1, 9, 3); // 1,4,7 E.RangeDownTo(1, -5, 3); // 1,-2,-5 E.ToInfinity(5, 3).Take(3); // 5,8,11 E.ToNegativeInfinity(5, 3).Take(3); // 5,2,-1
この辺、Rangeの直後にSelectで加工すればいいってだけの話ではあるんですけど、ショートカットが提供されるのも悪くないな、と思います。実際のLINQだってWhere(predicate).First()の短縮としてFirst(predicate)が用意されていたりしますしね。まあ、しかしこれでRangeの増減値に-1を使えるようにしておけば(今は無理です) RangeDownの存在意義が消滅してしまったことは気にしないことにします。
ToJSON
酷くバグッていたので修正。まーたポカミスです。最近、あちらこちらでポカミスを連発していて困りました。もっとちゃんとしたテスト書いておかないとダメですかねー。面倒くさくて簡易的というか手抜きというか、そんなようなテストしか用意していないので役に立っている度は半分ぐらいのようです。こうもクソバグを連発しているようじゃあ、どこがStableなんだよ、って話ではある。すみません。ごめんなさい。とりあえず、今度は、今度こそは大丈夫なはず。
まあしかし、追加はすぐなんですが、そのあとreference書いてtest書いて、ってのがダルくて追加作業を躊躇ってしまうんですよねー。うーん。この辺、もっと自動化というか、手軽に出来る仕組みを整備しないとダメですね。
そういえば、何だかんだでDL数が100を超えていました。ありがとうございます。100っていうのは、偉大な数字ですね。マイルストーンです。ニコニコ動画なんかでもそうで、普通に閲覧者として見ていると再生数1万以下の動画なんて存在しないに等しい、ぐらいの勢いですけれど、実際は1万以下の動画しかうpしてないような人のほうが多いんですから!遥かに!というような世界が見えます。で、それはそれで、幸せなのです。そもそもの目標が二桁であったことを考えると、三桁というのは嬉しい数字です。
