以下の文面は私に強制的にOTS対応のテーマを造れと執拗に言ってくるxcalに
対して述べているものです。
まあ、参考程度にしてください、思いは通じると思います。

OTSってテーマインストーラ造った連中が推進してるものなんだろ。
利点というかメリットというか今一良いところが理解できないんだよね。

太古の昔から構造かなるものはプログラミングの世界にあったのは確かだけど。
その部類ともかけ離れているように思える。
第一、メンテナンスしにくいし、OTS準拠を謳ってTheme.rcを記述してるつもりでも
最初の謳い文句以外はダラダラとコア以外の定義とかも記述されていたりする。

要するに理解できてるつもりでも、実際はできていないと言うことだ。
ディレクトリ構成を統一して、余計なフォルダを排除して手軽にメンテしやすくするのが
本来の目的なのではないだろうか、現状ではインストーラに合わせる為だけのモノとしか思えない。

実に下らんものだ。

これに固執する奴がいるとは(w

酷い連中なると、最初の謳い文句とNLMの記述だけで、コアrcもConfigに入れている(w
NLM対応にしておけばOTSだと思ってる(w
一番酷いのがpopupの定義なんだが、theme.rcにもconfigにも定義が入ってる奴(w
変数も専用のrcがあるにも関わらずに、scriptの中で沢山定義してる(w

ああ、それとIncludeすりゃOTSなんだよみたいな奴もいるな、
まあ、includeは構造化する上では欠かせない部分ではあるがOTSとは関係ないよな(w

もっと言うと、includeを上手に使って、ディレクトリ構成を十分吟味してキチンと分類してやれば
メンテのしやすいテーマが造れるはずである。
rcを全て把握しなくても肝となるrcを修正すれば済むというようなね。
それが構造化なんだろう？

なんかインストーラの為だけにOTSを普及させようとしても無理があるんだよな。

全く、システムとしてのLitestepを考えた場合は、構造化して弄りやすい造りやすいモノとして
rcの細分化、役割、ディレクトリ編成、それを統一させるためのルールを確立してから、
それに準じて初心者にも導入できるようにとインストーラを造るのが基本的な流れなんだろうけどな。

インストーラありきで話ができてるからな(w

キチンとした開発支援とか仕様とかができてるならOTSのような記述を勧められても
納得できるけど、それができていない以上はOTSのような無意味なインストーラの為だけの
記述を無理やり勧められる必要は無い。

OTSを推進する前に、標準化について今一度考えればいいのではないだろうか。

話はそれからだ。

OTS、OTSって馬鹿の一つ覚えみたいに人に押し付けるんじゃないよ(w