Jumpei Arakawa
araka****@infoc*****
2005年 11月 25日 (金) 04:04:13 JST
荒川です。
インライン■でコメントします。
| 池田です。
|
| インライン★でコメントします。
|
| Jumpei Arakawa wrote:
| > 荒川です。
| >
| > 結合則のリファクタリング案を示します。
| >
| > 骨子：
| > 1. 要素部と挙動部の結合に関しての違いをほぼなくす
| > 2. フィルタという概念を追加する
| > （3. 結果的に抽出則はなくなる）
| >
| > 1. 要素部と挙動部の結合に関しての違いをほぼなくす
| >
| > 現在、結合に際して要素部と挙動部のルールが異なりますが、
| > 挙動部の結合ルールを要素部のそれに合わせます。
| > つまり、後ろから結合するものが優先され、かつ追加するということです。
| >
| > { A | x, y, z | x + y + z } <+ { B | a, b, c | a + b + c }
| > => { B | x, y, z, a, b, c | x + y + z; a + b + c }
| >
|
| ★不都合が見つからなければ良いと思います。
| ただ、オブジェクトをオーバーライドする場合には不自然に感じるかもしれませ
| んね。下のフィルタと組み合わせればいけるかな。
■僕も最初まずいかなあ思ったのですが、挙動部が両方あるような
オブジェクトを積極的に結合するような場面が思い浮かばなかったんだよね（＾＾；
昔の議論の中でも、これ！っていうターゲットあったっけ？
個人的には、以前よりもっと「作れる感」が増えて、
魅力的なおもちゃになったみたいで嬉しいｗ
結合則をしっかりしていてかつシンプルなものにすると、
かなり強烈な「もの」感が出てくるような気がします。
頭の中にオブジェクトが図形化されてイメージできてしまうぐらいに。
（僕はすでにそうなりかけてるのですがｗ こいつはエキサイティングです）
|
| > 唯一の例外は、束縛に関しての穴埋めルールのようなものが存在しないことです。
| > また、以前あった内部名が共通の場合云々の話は特別扱いではなくて、
| > 内部名が同じなら自然と同じように見えるというだけのことになります。
| >
| > 当然ですが、nil（空の状態）の挙動部を重ねたとしても影響はありません。
| >
| > { A | x, y | x + y } <+ [ 1, 2 ]
| > => { A | x = 1, y = 2 | x + y }
| >
| > これに関連して便利な識別子itを考えました（itという名称は仮称）。
| > itは、事前の評価結果を束縛結果としてもつ識別子です。したがって、
| >
| > { do-something } <+ { print: it }
| > => { do-something; print: it}
| >
| > 等で簡単に表示処理等を埋め込むことが可能になります。
| > （まあ、このこと自体は以前のルールでも可能でしたが）
| >
| > 2. フィルタという概念を追加する
| >
| > このフィルタという概念はメタ結合の最初からのイメージである
| > 「重ねる」というものから自然に発想したものです。
| > （以下の表記はまだ仮のものです。問題があれば変えましょう）
| >
|
| ★表記についてはわかりにくいような・・・ｗ
| 前知識なしで読み取れば同じ空オブジェクトになりそうだし。
| まぁ記号不足なので難しいですが。要検討。
■記号をつけるのも考えたのですが、前知識なしで混乱、というよりむしろ、
以前のオブジェクトの定義（という既存知識）に対しての混乱でないですか？
最初からそういう風な定義だ、とした場合にそれほど
混乱を起こす元になるかなあ、という気はしますが、詳しくは四つ下の■で。
|
| > { | | }
| >
| > これは、内部名、要素部、挙動部を全て透過させるフィルタです。
| >
| > { || }
| >
| > これは、内部名と挙動部は通しますが、要素部を通さないフィルタです。
| >
| > { | |}
| >
| > これは、内部名と要素部は通しますが、挙動部は通さないフィルタです。
| >
| > {| | }
| >
| > これは、要素部と挙動部は通しますが、内部名は通さないフィルタです。
| >
| > {||}
| >
| > これは、内部名、要素部、挙動部のいずれも通さないフィルタです。
| >
| > 冗長なので全てを列挙はしませんが、要するにスペースのふさがった記述で「非透過」を示します。
| > 例えば、
| >
| > { A | x, y | x + y } <+ { || }
| > => { A | | x + y }
| >
| > となり、フィルタがかかったことで、要素部が通れなくなり、重ねたときに上から見えなくなりました。
|
| ★削ぐわけではなくて隠すんですよね。Rubyのundefと似てます。
| フィルタと呼ぶとちょっと語弊があるかもしれない。
| マスクとか、カバーとか、シールドとか？
■あんまりundefという気はしないかな。内部名や挙動部にも使えるわけで。
要素部の一部に対してできればそうかもしれないけど、
undefとかの対象はあくまでmieでいう束縛だから、もっと限定的な感じがする。
あと名称だけど、シールドだと重ねられる感じはしないなかなあ。
あと、通す部分と通さない部分があるっていうのを言いたいので・・・。
イメージ的にどうもマスクもカバーも「厚い」気がしてしょうがないですｗ
（あとマスクはビットマスクのイメージも強くて、焼き付ける感じもあるなあ）
フィルタは個人的に「薄い」感じがしたのでそういう名称にしてみました。
図形的・機能的には「ゲート」が一番ぴったりだとは思っているのですが、いかんせん「重い」のですｗ
まあ、とりあえず名称は保留ですねえ。イメージとしては○○をさしこむとかはさむっていった感じ。
| > これを使うことで、前回のメールでいった「強い」オブジェクトを作ることができます。すなわち、
| >
| > .a = { | |} <+ { aを取り出す処理 }
| > { A | a = 1 | do-something } .a
| > => { A | a = 1 | do-something } <+ ({ | |} <+ { aを取り出す処理 }) !
| > => { A | a = 1 | aを取り出す処理 } !
| > => 1
| >
| > となります。これは対象オブジェクトとaを取り出す処理を持つオブジェクトの
| > 間にフィルタが入ることで、do-somethingを見えなくしたからです。
|
| ★うん、やっぱりこれだとわかりにくいから目立つ記号を入れたい気分。
| フィルタていう概念はオブジェクトに新しい性質が加わったということになりま
| すよね。普通のオブジェクトは{ | | }というフィルタを性質として持っている
| と。んでフィルタはメタ結合時に必ず左側が引き継がれるということでしょう
| か。
■左？右の間違い？（すまん、ちょっと質問の意図が分からんです＾＾；）
「フィルタは」とかではなくメタ結合自体をすべて「上」優先にしたということです。
メタ結合のルールをシンプルにしようというのがそもそもの発端なので。
「メタ結合というのは重ねるイメージですよ」といって説明するには
今までのルールはちょっと複雑になりすぎているような気がしてました。
なので、今回のリファクタリングで狙ったのはイメージと現実の差を埋める事です。
| 便利そうだけど、漠然とした不安が無きにしも非ずというのが正直な感想ｗ
■まあ、それはあるｗ
| 表記の一案としては、
| { | | } → [___]
| {||} → [///]
| とか。見た目重視で。
■うーん、正直なところ、これ以上やたらに記号増やしたくないなあ、という感じです（＾＾；
（覚えるのも説明するのも大変そうな気がするので・・・）
表記に関しては、普通の{ | | } とうまく折り合いのつけられる表現でないとまずいですね。
{ | | }を普通の空オブジェクトとすれば通過ですから、もう片方の表現は非通過でなければなりません。
{_|_|_} 一応、これが以前に考えていた_を使った非通過のフィルタの記述イメージです。
まあ、これに関しては「通さない」というのをどう伝えるかという問題になりますかね。保留。
# 言語設計者ってある意味AA職人だよねｗ
|
| んでフィルタ自体もフィルタ対象とできたりするとどうなるんだろうとか・・・ｗ
|
|
| > 強いオブジェクトというのは我ながらちょっと無理やりな気がしたのですが、
| > 重ねるというイメージからいってフィルタがあるというのは個人的にしっくりきました。どうでしょう？
|
| ★強いオブジェクトというのは私もちょっと微妙だと思ってました。
| レスしてなくてすみません。ちょいパワー不足で。
■パワーのあるときないときあるのはお互いさまなので（＾＾；
まあ、レスはなくとも、池田君の思考ルーティンへの刺激になってればOKですｗ
|
| > _______________________________________________
| > mie-dev mailing list
| > mie-d****@lists*****
| > http://lists.sourceforge.jp/mailman/listinfo/mie-dev
| >
| >
| _______________________________________________
| mie-dev mailing list
| mie-d****@lists*****
| http://lists.sourceforge.jp/mailman/listinfo/mie-dev