re:僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - ぐるぐる～
元ネタ: 僕にとってMaybe / Nullable / Optional が、どうしてもしっくりこないわけ。 - 亀岡的プログラマ日記 OOPの文脈で見ると、元の記事が言っていることもわからなくはないのですが、対象が広すぎていろいろと不正確になってしまっているので、ちょっとまとめてみます。 元の記事が対象にしているのは、Maybe / Optional / Nullableの3つです。 対応する型を持つ言語を見てみると、下記のようになります。 Maybe(Haskell) Optional(Swift/Java) Nullable(C#) これらは、「値がないこと」を表すもの、という見方では同じですが、それぞれ異なる価値観の元に作られています。 Maybe/OptionalとNullable これらはすべて型パラメータを取ります*1。 しかし、この中でNullableだけは型パラメータに
SQL Server Management Studio でテーブルのデザインを変更できるようにする - ぐるぐる～
いつも忘れるのでメモ。 SQL Server 2008 の SQL Server Management Studio では、テーブルのデザインを変更しようとしても、 変更の保存が許可されていません。行った変更には、次のテーブルを削除して再作成することが必要になります。再作成できないテーブルに変更を行ったか、テーブルの再作成を必要とする変更を保存できないようにするオプションが有効になっています。 なんてエラーが出て出来ない場合がある。 これを回避するためには、 メニューから「ツール」を選ぶ 「オプション」を選ぶ 左側のツリーから「デザイナ」を選ぶ 右側の「テーブル オプション」から「テーブルの再作成を必要とする変更を保存できないようにする」のチェックを外す とすれば、出来るようになる。
遅延評価ってなんなのさ - ぐるぐる～
何なんでしょうね。分かりません。 自分の頭の中をとりあえず整理するためのエントリなので、あなたの頭を混乱させるだけになるかもしれません。 もし混乱してしまったら忘れてください。え、無理？忘れてください。 自分の考えを明確にしたので、こちらをどうぞ。 遅延評価いうなキャンペーンとかどうか - ぐるぐる～ これは遅延評価ですか？ 関数を渡すだけ // Scala def hoge(f: Unit => Int) = for (i <- 1 to 2) println(f()) (* F# *) let hoge f = for i in 1..2 do printfn "%d" (f()) この関数に渡す f は 2 回実行されます。そのため、f の中で画面出力をしていた場合、2 回出力されます。 これは遅延評価でしょうか？俺は違うと思います。 ここは多くの人で合意が取れると思ってます。 Sc
生島さんが考える最強の言語 SQL - ぐるぐる～
生島さんが誰と闘っているのか知らないけど、ちょっと気になることをつらつらと。 SQLは最も高級言語 - SQLer 生島勘富 の日記 SQLは最も高級言語２ - SQLer 生島勘富 の日記 SQLとはなんぞや？ - SQLer 生島勘富 の日記 高級*言語* どうも生島さんは、「SQL は高級言語！」と言いつつ SQL の処理系 (RDBMS) のことを高級だと言っているようです。 言語が高級であることと、処理系の最適化が手厚いことをごちゃまぜにして、この言語高級！と言うのはまずいんじゃないでしょうか。別に、RDBMS を操作するための言語として SQL でなくたっていいのです。例えば Tutorial D/Industorial D もあるし、LINQ を SQL に変換せずに直接 DB の操作を行うような RDBMS/Linq to X と言うのも考えられます。 ここではとりあえず、
例外について色々と考えてみた - ぐるぐる～
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる〜から派生して、 「他の例外クラスを継承しただけの例外クラスを作らない」に不同意の理由 - Diary of Dary、 例外クラスの指針 - 猫とC#について書くmatarilloの雑記や、さらには Twitter で Java の検査例外と非検査例外についての議論へと発展したので例外についてまじめに考えてみた。 あくまで、今の自分の考えなので真に受けない方がいいかも！そもそも経験が少ないので、トンチンカンなことを言ってるかもしれません。 あ、それと、用語は基本的に Java から取ってきています。ただ、メソッドじゃなくて関数を使っているけど、これに深い意味はありません。多分。 例外とは まず、例外とは一体何者なのか、ということ。 ここでは面倒を避けるために、Meyer 先生の定義を借りること
オブジェクト倶楽部、コーディング規約の会の「C# コーディング標準」の駄目なところ - ぐるぐる～
C# のコーディング規約としては、オブジェクト倶楽部のもの (PDF) が有名だけど・・・正直、これ使いたくない。 冒頭に「このドキュメントは Java コーディング標準(オブジェクト倶楽部バージョン)、VB.NET コーディング標準を C#用に変更したもの」なんて堂々と書いてる時点で・・・ で、この規約のどこが駄目なのか、なぜ駄目なのか、どうすればいいのかをまとめてみた。 なんだかんだで長文エントリ。 追記： ちなみに、C# の規約としてはクラス ライブラリ開発者向けのデザイン ガイドラインで十分だと思う。 更に追記： ブコメで教えてもらったんだけど、どうやらクラス ライブラリ開発のデザイン ガイドラインの方が新しいらしい。 2. ファイル構成 (1) ファイル名 public クラスはそのクラス名の 1 ファイルにする。 例：public class Customer は、Custom
流れるようなインターフェイス - ぐるぐる～
なんか単に 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
カプセル化、情報隠蔽、データ隠蔽 - ぐるぐる～
あちこちのサイトを見てると、間違った解釈をしてるのが多い。カプセル化なんて、情報隠蔽まで含んでるのが常識になりつつあるような。。。ここまで一般化してると情報隠蔽してるのがカプセル化というのが常識なのかも。 カプセル化・情報隠蔽・データ抽象化 - 今日の役に立たない一言 − Today’s Trifle! − カプセル化と情報隠蔽、データ隠蔽の違いがよくわからくなったので、手持ちの本で調べてみた。 基準 基準としては、 カプセル化、情報隠蔽、データ隠蔽の関係 カプセル化は隠蔽を含んでいるかどうか 対象はクラスのみか、そうでないか などなど。 一番目はそのまんま。二番目は、 // 隠蔽せずともカプセル化か class Hoge { int hoge; // なんかhogeを使うメソッド } // 隠蔽しなければカプセル化ではないか class Piyo { private int piyo;
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
