青木です。

  In mail "[ruby-reference-manual:55] Re: 作業マニュアル #1 (フォーマット変換)"
  SASADA Koichi <ko1@a...> wrote:

> 　ささだです。
> 
> 　仕様のたたき台が出たらその後で議論、と思っていたんですが、もう決定にな
> るんでしょうか。日記での仕様検討はあんまり読んでません。ML で議論する前
> のたたき台作りだとばかり思っていたから。

決定ではないです。とりあえず作ってみないと話が進まないぽいから
作ってます。叩き台にするなら、仕様ではなくて現物 (ソースコード)
を叩き台にしたい。


> 　気になっていたのが、
> 
> ・ドキュメントの構造
> 　http://www.typemiss.net/blog/kounoike/20060120-54
> 　この辺で出ている話。

これは出力の話なので、どうとでもなると思います。いまやってるのは
あくまでも入力側の話です。つまり、出力前にすべて一回パースされて
データベースに入れてそこから動的に生成されます。

なんで今回形式を変えるかというと、厳密にパースして、メタデータを
きっちり取れるようにするためです。例えばスーパークラスとか include
してるモジュールとか require してるライブラリを自動的に検出できる
ようにしたいんです。あと Ruby のバージョンによる違いかな。

また、他のメソッドやクラスへのリンクもずっと簡単、かつ統一的になります。


> ・ライブラリに複数のクラス、モジュールがある場合は全部きちんと分ける？

「きちんと分ける」というのはどういう意味でしょうか？


> ・目次の作り方
> 　今は全部手作業ですが、自動化できるか？

ある程度自動化できると思っています。例えばクラスツリーなんかは
自動生成にして、適当なテンプレートシステムを使ってそれを埋め込む
ような形式を想定しています。


> ・パラメータ（引数）、返り値の型はどう表現する？

いまのとこ型をメタデータとして保持することは考えていません。
しかし、TMail とかのリファレンスでは型もぜんぶ書いてるので、
その仕組みをもってくれば実装は可能です。あとは「やるか、
やらないか」ですね。個人的にはやりたいですけど、手間がどうかな。

--
青木峰郎

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