ささだです。

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

　なるほど。

>> ・ドキュメントの構造
>> 　http://www.typemiss.net/blog/kounoike/20060120-54
>> 　この辺で出ている話。
> 
> これは出力の話なので、どうとでもなると思います。いまやってるのは
> あくまでも入力側の話です。つまり、出力前にすべて一回パースされて
> データベースに入れてそこから動的に生成されます。
> 
> なんで今回形式を変えるかというと、厳密にパースして、メタデータを
> きっちり取れるようにするためです。例えばスーパークラスとか include
> してるモジュールとか require してるライブラリを自動的に検出できる
> ようにしたいんです。あと Ruby のバージョンによる違いかな。
>
> また、他のメソッドやクラスへのリンクもずっと簡単、かつ統一的になります。

　各クラスに Summary とか要らないのかな、とかが元の質問の意図でした。


>> ・ライブラリに複数のクラス、モジュールがある場合は全部きちんと分ける？
> 
> 「きちんと分ける」というのはどういう意味でしょうか？

　net/http.rb だったら、現在はライブラリごとに1つのページ（Net::HTTP、
class Net::HTTPRequest、class Net::HTTPResponse が1つのページ）ですが、
webrick.rb は各クラスごとに複数ページに分離されています。

　意図としては include で1つのページにまとめることを狙っていると思うので
すが、WEBrick や optparse は長大になりそうです。

　どちらを取るんでしょう。


>> ・目次の作り方
>> 　今は全部手作業ですが、自動化できるか？
> 
> ある程度自動化できると思っています。例えばクラスツリーなんかは
> 自動生成にして、適当なテンプレートシステムを使ってそれを埋め込む
> ような形式を想定しています。

　了解です。


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

　悩ましいですね。to_str を持つオブジェクト、なんてどう表現するんだか。


-- 
// SASADA Koichi at atdot dot net


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