青木です。

  In mail "[ruby-reference-manual:256] superclass"
  Kazuhiro Yoshida <moriq@m...> wrote:

> moriqです。
> 
> どこにも書いていないような気がするので念のため。
> 
> クラス名はなんとなくトップレベルから書いていますが、
> 継承している場合スーパークラス名はトップレベルから書くべきでしょうか。
> = class Tk::BLT::PlotComponent::BitmapMarker <
> Tk::BLT::PlotComponent::Marker
> 
> できれば省略して書きたいものですが。

いまのところ、クラス名・モジュール名はすべて絶対パスを想定しています。

> あと include, extend は相対位置でいいんですよね。

いえ。絶対パスです。


Ruby で言うところのモジュールのネストができるようにしようかと思わなくも
ないんですが、けっこう厄介なんですよね。Ruby の定数の挙動を真似ることに
すると、「::Enumerable」みたいのをちゃんと実装しなきゃいけないとかいろ
いろあって、非常に繁雑です。かといって、似たような記述で別の挙動をすると、
それはそれで混乱しますし。あと #@include があるので、規則を工夫しないと
変なところに効果が波及する可能性があります。

それと Ruby と BitClust の一番違うところは、include したり継承したり
するクラスの情報が先に得られるとは限らないところです。つまり、スーパー
クラスより前にサブクラスをパースする可能性があります。それどころか永久に
スーパークラスが得られない可能性もあります。そういう条件だと、例えば
「どのレベルに定数 C があるからどーのこーの」という手段が使えないので、
Ruby より記述量が増えるのは確定です。

それに、コンテキストを増やせば増やすほど扱いにくくなるんで、できるかぎり
コンテキストは増やしたくありません。BitClust のパーサで対応するのはどうに
かなっても、その外で簡単にツールが作れなくしてしまうことには抵抗があります。

以上を踏まえたうえで、プリプロセッサでテキスト的にどーにかする方法はアリ
かなあと思っています。ただしプリプロセッサで文法にまでは立ち入りたくない
し、あんまり汎用的すぎると C/C++ のマクロみたいなことができてしまうので
よろしくありません。というわけで、例えば

  #@defprefix Tk::BLT::PlotComponent

と書いといて

  = class #@<prefix>::BitmapMarker < #@<prefix>::Marker

と展開する、とか……ああこれでもちょっと汎用的すぎるかなあ……。
なんにでも使えてしまいそうだ。

--
青木峰郎

--
ML: ruby-reference-manual@m...
使い方: http://QuickML.com/