NullableとOptionの違い - ぐるぐる～
このエントリの最新版はGithubにあります。 Optionそのものについてのエントリは書く必要ない(世の中に有用なドキュメントが山ほどあるから)かな、 と思っていたのですが、Nullableとの違いについてはそれなりに需要がありそうなので書いておきます。 ちなみに、個人的な嗜好によりOptionを持ち上げ、Nullableを下に扱う感じになっていますが、Nullableも(仕方なく)使うことはあります。 特別な理由がなければNullable使わずにOptionを使う、ということでもありますが、そこは一つよろしくお願いします。 Nullableとは C#ではnullは参照型でしか使えませんでした。 Nullableは、この制限がない(ように見えるよう特別扱いされている)唯一の値型です。 ジェネリック型になっており、任意の値型を扱うことが出来ます。 // Nullable<int>はint?
C# 使いから見てうらやましい Java8 の default 実装の使い方 - ぐるぐる～
Java8 から追加されるインターフェイスの default 実装ですが、C# の拡張メソッドに似てますよね。 実際、このどちらも「シンインターフェイス」を定義するだけで「リッチインターフェイス」が手に入ります。 しかし、C# の拡張メソッドと Java のインターフェイスの default 実装には、それぞれの利点と欠点があります。 拡張メソッドの利点 拡張メソッドの利点は、インターフェイスの実装者だけでなく、 インターフェイスの使用者に対してもインターフェイスの拡張が開かれている点です。 既存の型ですら、後付けでメソッドを追加することができるということです。 using System; public static class StringExtension { // インターフェイスでなくても、どんな型に対しても拡張可能 public static int ToInt(this str
並列/並行基礎勉強会でasync/awaitをDisってきた - ぐるぐる～
async/await不要論 from bleis tift 3/23 に開催された、並列/並行基礎勉強会で「async/await 不要論」という発表をしてきました。 一番言いたかったこと 一番言いたかったことは、実は並列とかとは全く関係ないことです。 それは、言語への機能追加に関することです。 C# は 5.0 で非同期処理のための専用の構文として、async/await を導入しました。 これは、F# が計算一般という抽象度の高いものための汎用的な構文として、コンピュテーション式を採用しているのとは対照的です。 専用の構文を用意するかしないかは、その言語を取り巻く環境次第です。 専用の構文の利点と欠点 専用の構文の利点は、その使用用途が明確であるというところにあります。 そのため、書き方さえ覚えてしまえば、その裏で何がどうなるかなどを一切気にせずに使えてしまえたりします。 欠点は、専
遅延評価いうなキャンペーンとかどうか - ぐるぐる～
遅延評価については以前も書いてるんですが、そのときは結論なしでした。 が、ちょっと考えるところがあって、言語を Java に絞って自分の考えを明確にしておきます。 結論から書きましょう。 「Java(とC#) で遅延評価って書いてあるものは遅延評価ではない」です。 Java における「評価」とは まず一番最初に、Java で「評価」って言うと、どういうことを指すのかを確認しておきます。 言語仕様の該当部分を要約すると、こんな感じでしょうか。 プログラム中の式を評価すると、結果は 変数 値 無し のうちのどれかとなる。 評価した結果が値になる、というのはいいでしょう。それ以外の 2 つを軽く説明します。 評価の結果が「変数」とは？ コメント欄で指摘が入っています。 代入の結果は変数ではありません(15.26)。 結果が変数となるのは、ローカル変数、現在のオブジェクトやクラスの変数、フィールド
わかめのモナ化で色々やってきた - ぐるぐる～
わかめのモナド浸し - connpass ハンズオンの前座として、Maybe モナドと State モナドの解説をしました。 モナドハンズオン前座 from bleis tift 発表も資料も割と好評なようで、「モナドの教え方」みたいなものの感覚もつかめたので発表してよかったです。 モナド則とかそういう、ふつうのプログラマにとって難しい言葉は使ってないので、気負わずに読めると思います。 ただやはりState モナドは難しかったようで、ハンズオンでも State の追加説明をしたりと、ここら辺はまだ改善の余地ありですね。 実は書きたかったことが書ききれてはいないので、どっかで書きたかったことを追加したバージョンも作りたいところです。 参加者の反応は上々なようです。よかったよかった。 皆様大変ありがとうございました！往復二万円の価値が十分にある勉強になりました！来年またよろしくお願いします！
rebase について - ぐるぐる～
rebase 便利だよ、というだけのエントリです。 AA で書いてる部分は時間があれば画像に置き換えます。 rebase とは ブランチを作成した場所を変更することと理解しています。つまり、そのブランチの「親」を変更する、ということです。 もう少し動作に踏み込むと、指定したコミットの後ろに現在のブランチで行ったコミットをリプレイするように適用します*1。単なるリプレイではなく、その過程をいじくれるのが rebase のすごいところです。 単純な rebase はたとえばこんな感じです。 以下のようなリポジトリの状態があったとして (現在チェックアウトされているブランチは dev ということを表すのに * を使っています)、 1---2---3 *dev / A---B---C---D master次のコマンドを実行します。 $ git rebase masterこれにより、リポジトリの状態
コンフリクトが発生しなくても壊れる場合 - ぐるぐる～
push したら誰かが先に push していたので失敗した。 なので pull したが、コンフリクト (競合) は発生しなかったので何も確認せずにそのまま push した。 何も問題なさそうですね。 ・・・本当ですか？ 例えばこんな状況を考えてみましょう。 最初の状態 A さんと B さんと C さんが登場します。 作っているのは Web ページで、コードはこんな感じ。 <html> <head> <title>hoge</title> <style> .menus { overflow: auto; } ul { margin: 0; padding: 0; list-style-type: none; } .button { float: left; width: 100px; margin: 0; padding: 10px 0; text-align: center; backgr
SCM Boot Camp 2 in Tokyo に行ってきた - ぐるぐる～
今回は Git の講師として参加しました。 2 回目と言うこともあって、よりスムーズに進めることができたように思います。 個人的なもくろみ 今回参加して、SCM Boot Camp の DVCS イベントの部分はある程度パッケージ化したいと考えるようになりました。 まだ 2 回しかやっていませんが、DVCS (少なくとも Git) の効率的な習得のためのスキームというのが見えてきた感じです。 最終的には、講師が 1 人いれば小規模なイベントを開くことのできるところまで落とし込めるのでは、と考えています。 以下時系列順の雑多な感想や補足など 開催前 今回は、開催の準備として数回 Lingr によるミーティングを行いました。 資料の作成も段階的に行うことができたのでフィードバックを取り入れることができてとてもよかったです。 にも関わらず、 30秒前までずっと作り続けていたらしいので、たぶんあり
More Effective C# - ぐるぐる～
More Effective C# 作者: Bill Wagner,長尾高弘出版社/メーカー: 翔泳社発売日: 2009/12/01メディア: 大型本購入: 9人 クリック: 139回この商品を含むブログ (19件) を見る を読むに当たって、注意すべきかなー、と思ったところをだらだらと。 ICloneable は実装すべきではない ICloneable を実装することはお勧めできません†。 †：『Framework Design Guideline : Conversions, Idioms, and Patterns for Reusable .NET Libraries』(著／ Krzysztof Cwalina, Brad Abrams 刊／ Addison-Wesley) を参照してください。 More Effective C# 項目 1 1.x フレームワーク API のクラス
例外について色々と考えてみた - ぐるぐる～
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも！そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
構造体 - ぐるぐる～
C++の構造体とクラスはデフォルトのアクセスレベルが違うだけで、それ以外は全く同じだが、C#の構造体とクラスはかなりの違いがある。 class struct 格納場所 ヒープ スタック*1 継承 可 不可*2 *3 メンバの制限 なし あり*4 フィールドの宣言箇所での初期化 可能 不可能 コレクションとの相性 良い 悪い*5 また、ボックス化解除は明示的に行わなければならないのに、ボックス化は何も考えずにできるから思わぬところでボックス化が起こったりする点も注意が必要。 int i = 0; // ここで勝手にボックス化 Console.WriteLine("{0}", i); // 勝手にボックス化されないように明示的にToStringで文字列に Console.WriteLine("{0}", i.ToString()); // むしろこの例だったらこれでOK Console.Wri
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
条件演算子・・・厨？ - ぐるぐる～
名前 症状 僕の状態 三項演算子厨 どんどんネストした三項演算子を書いてしまう．気が付くと自分でも良くわからなくなってる事もある 治療済み プログラマの麻疹 - YoshioriのBlog 三項演算子は多分条件演算子のことだろう、ってのはいいとして、ネストした条件演算子は書き方が悪いだけです！と言ってみる。 三項演算子?:の正しい書き方 で、ここのブクマコメに、id:nekora 「うーむ。一理あるような気がするけど、私ならifにする。」とか、id:PoohKid 「if文を1行で表記したいから三項演算子にするんだよね…」とか、id:sqrt 「改行したくなるほど複雑な表現になったら?:を諦めてif文などに置き換えるのがベストプラクティスだって偉い人がゆってた。だから、三項演算子は1行で書くのが正しい書き方。」とかあるんだけど・・・違うよ！全然違うよ！ if 文を条件演算子で置き換えること
流れるようなインターフェイス - ぐるぐる～
なんか単に this を返せばいいって思っている人も多いようけど、ただ this を返せばそれが使いやすいかって言われると、正直微妙。 例えば、 public static class StringUtil { public static SubstrInfo Substr(this string str) { return new SubstrInfo(str); } public sealed class SubstrInfo { public SubstrInfo From(int from) { ... return this; } public SubstrInfo To(int to) { ... return this; } public SubstrInfo Length(int length) { ... return this; } } } なんてクラスは、 "hoge
値渡しと参照渡し (と参照の値渡し) - ぐるぐる～
値渡しと参照渡しは、分かってしまえば何も難しいところはないんだけど、分かるまでにちょっとした壁があるというかなんとうか・・・ てことでちょっとまとめておきますねー 値渡し (call-by-value) と参照渡し (call-by-reference) の違い 値渡しと参照渡しの違いは、「呼出し元の値自体を変更できるかどうか」と説明されることが多い。 しかし、例えば Java ではミュータブルなオブジェクト *1 を渡した場合、呼出し元の値自体を変更できるという勘違いをする可能性があるため、この説明はあまり好ましくない。 そのため、参照渡しを「呼出し元の別名を渡している」と覚えるのが分かりやすいと思う。 値渡しは「何かの値をコピーして渡している」と覚える*2。 Java の場合 Java には値渡ししか存在しないが、「参照型」のためにややこしく感じる。 参照型は参照渡しとは無関係で、C
strong typedef しててもアプリケーションハンガリアンが有効な場合はある - ぐるぐる～
strong typedef するってなんだ、ってのは置いとくとして、適切な名前の基準三つ。を読んでちょっと思ったことが、上のタイトル。 どういう状況かというと、変数名の補完機能の付いたエディタ*1で GUI プログラム書いてるとか、そんな感じ。 GUI コンポーネントは Button クラスだとか、Label クラスだとか、十分 strong type なんだけど、一つの画面に貼り付けるコンポーネントが多い上、GUI コンポーネントは非常に多くのメソッドを持ってるのが普通だから、補完機能があまり役に立たない*2。 これを避けるために、アプリケーションハンガリアンを併用して、 Button オブジェクトにはプレフィックス btn_ Label オブジェクトにはプレフィックス lbl_ を付けるとかすると、btn_ と打って補完機能を働かせれば、ボタン一覧が表示される。 そういえば、この場合
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
