«前の日記(2005年04月06日) 最新 次の日記(2005年04月08日)» 編集

Matzにっき

<< 2005/04/ 1 1. [Ruby] 『ルビま!』休刊のお知らせ
2. [Ruby] emerald 0.1
2 1. エイプリルフール種明かし
2. [言語] Stricter Whitespace Enforcement
3. [OSS] オープンソースで育て! 日本のソフト開発力
4. マツダがリコール MPV・プレマシーなど6万台
5. [言語] Javaのメモリ消費問題の解決を目指すSunのプロジェクト「MVM」
6. [原稿] UNIX USER 6月号
7. 散髪
3 1. [教会] 松江
4 1. [教会] セミナリー
2. Progenyの改革:FOSS企業がいかにしてドットコム崩壊を生き延びたか
3. 捻挫に...
4. 論文
5 1. [Ruby] A Poll
2. [言語] Trails
6 1. [OSS] サンのJ・シュワルツ、オープンソースライセンスのGPLを批判
2. [Ruby] Objectクラスの上
7 1. 花粉
2. [Ruby] 続、Objectの上
8 1. [OSS] No More Free BitKeeper
2. 桜
3. [原稿] 日経Linux
4. [OSS] OSI、オープンソースライセンスの分類に乗り出す
9 1. [教会] 桜と総大会
10 1. [教会] 桜と総大会(その2)
11 1. [家族] 入学式
2. [Ruby]高橋メソッド
12 1. [原稿] 日経Linux 6月号
2. [言語] バールのようなもの
13 1. [特許] 特許における「発明」とは何か
2. [OSS] マイクロソフトのOOoに対する姿勢は新手のFUDか?
3. [Ruby] Objectの上(その3)
4. U-20プログラミングコンテスト実行委員会
14 1. 誕生日
2. 献血
3. ヒゲ
15 1. SCIgen - An Automatic CS Paper Generator
2. [OSS] OSCJ.net、オープンソフトOSS開発支援プロジェクトが発足
16 1. ドラマに見る「緊急対応」に対する一般的イメージ
2. [家族]バプテスマ会
17 1. [教会] 米子
18 1. TCPフロー制御アルゴリズムは人のマネージメントへ応用できるか
19 1. [Ruby] Rails Day
20 1. [言語] Dynamic Languages Symposium 2005
2. ある「ハッカー」の顛末
21 1. [OSS] L・トーバルズ、新しいLinux開発管理システムに「Git」を選択
22 1. Why Smart People Have Bad Ideas
2. [Ruby] 新GC
23 1. 「1週間コンピュータなしで暮らそう」--米で『無使用週間』実施へ
2. [家族]買い物・食事
3. アクセス
24 1. [教会] 倉吉支部大会
25 1. [用事] 自転車運搬
2. [Ruby] 新GC
26 1. [言語] Lightweight Language Day and Night(通称:LLDN)
2. [Ruby] YARV?
27 1. [Ruby] Ruby is the "Most Loved" programming language
2. [Ruby] 訃報x2
3. [Ruby] スクリプト言語人気に思う,動的型付け言語の可能性
4. プロポーショナル? 固定ピッチ?
28 1. [言語] PEP #340 Anonymous Block Statements
2. 論文
29 1. [家族] 宍道ふるさと森林公園
30 1. 論文書き
>>

2005年04月07日 [長年日記]

_ 花粉

が、飛んでいるらしい。今年は鼻炎の症状はまったくないが、 花粉にさらされると、喉がイガラっぽくなるのと、頭が重くなる。 〆切やらなんやらが重なっている時に思考力が下がるのは大変困る。

_ [Ruby] 続、Objectの上

なんとたくさんのツッコミがあったことか。今までで最大ではないだろうか(そうでもないかな)。

いただいた名前の候補は検討材料としたい。

「空っぽ」系
Void, Blank, Emptyなど。 しかし、Objectのスーパークラスであることを考えるとこれら「空っぽ」系は採用しがたい。 Objectの継承ツリーとは独立に導入するならあり得るかもしれないが、 それでも、たとえばDelagatorは「空っぽ」のサブクラスというのは奇妙に感じる。 EiffelではVoidはスーパークラスではなく、すべてのクラスのサブクラスとして定義してあるのが興味深い。
自己言及系
RubyとかMatzなど。少なくとも私が管理している範囲内ではRubyに自己言及的な名前を導入したくない。 Rubyインタプリタ自身を操作するクラス/メソッドにならともかく「すべてのRubyクラスの頂点」である という理由でRubyという名前を使いたくない。ましてやMatzなど。
比喩系
Atom, Idea, Heart, Ghost, Shellなど。 「〜のようなものだから」という理由は誤解を生みやすいので安易に導入できない。 ただし広く使われているので説明されれば納得できるようなものは除く(たとえばネットワークIOにおけるSocketとか)。 今回はそれに該当するものは、Rootくらいか。

ケチつけるだけで申し訳ない。 まだ、考えがまとまっていない。


«前の日記(2005年04月06日) 最新 次の日記(2005年04月08日)» 編集