modified to fit with created subdirectories: programs/, install/,

delivery/, internals/, devel/ and include/.

1 files changed, 161 insertions, 0 deletions

diff --git a/fml/doc/ja/tutorial/internals/style.sgml b/fml/doc/ja/tutorial/internals/style.sgml
new file mode 100644
index 00000000..87365aa2
--- /dev/null
+++ b/fml/doc/ja/tutorial/internals/style.sgml
@@ -0,0 +1,161 @@
+<!--
+	$FML: style.sgml,v 1.1 2001/04/26 08:58:36 fukachan Exp $
+-->
+
+<chapter id="programingstyle">
+
+<TITLE>プログラミング・スタイル</TITLE>
+
+<para>
+ここでは、プログラミング上のいくつかの諸問題についてまとめます。
+</para>
+
+
+<!-- ==================================================== -->
+<sect1 id="variable-naming-convention">
+
+<title>
+変数の命名規則（ネーミングコンベンション）
+</title>
+
+	<sect2>
+	<title> 標準パターン (例 log.cf lock.cf) </title>
+
+<screen>
+use_変数		=	yes/no
+
+# ディレクトリなら最後に _dir がつくことが望ましい
+変数_dir		=	文字列
+
+# ファイルなら最後に _file がつくことが望ましい
+変数_file		=	文字列
+
+変数_type		=	文字列
+
+変数_format		=	文字列
+
+変数_format_type	=	文字列
+
+変数_limit		=	文字列(数字だけど文字列扱い)
+
+変数_upper_limit	=	文字列(数字だけど文字列扱い)
+
+変数_lower_limit	=	文字列(数字だけど文字列扱い)
+</screen>
+
+	</sect2>
+
+	<sect2> 
+	<title> パターン２ (例 acl.cf ) </title>
+
+<screen>
+変数_restrictions	=	reject_属性 
+				permit_なんとか
+
+属性 			=	パターン1
+				パターン2
+				…
+</screen>
+	 </sect2>
+
+
+	<sect2>
+	<title> パターン3 (さらにプログラム名がつく場合) </title>
+
+<screen>
+プログラム_変数_属性
+</screen>
+	 </sect2>
+
+
+</sect1>
+
+
+<!-- ==================================================== -->
+<sect1>
+
+<title>
+プログラミング・スタイル (原案のメモ(注: 単なる走り書き))
+</title>
+
+<para>
+<itemizedlist>
+	<listitem>
+	<para>
+	
+	Perl ではポリモーフィズムと実行時バインディングができることに
+	は重視すること。多重継承などに頭を使うより
+	ポリモーフィズムと実行時バインディングによる
+	コンポーネント指向ぽい方向性を模索する。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	Perl 5 のパッケージを使った、オブジェクトぽい書き方は
+	変数自身が自分のパッケージを知っているので、
+	単にパッケージ修飾(例: :: )を使わなくてもよいくらいに
+	思う方がよい。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	そのために、
+	再利用性と抽象度を高くしたインターフェイスは
+	オブジェクトぽい書きかたが良さそう。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+	perl 5 だと必然的にオブジェクトぽくなってしまうが、
+	オブジェクト、オブジェクト、オブジェクトし過ぎないように
+	バランス感覚に注意しよう。
+	</para>
+
+
+	</listitem>
+
+	<listitem>
+	<para>
+	
+ 	他人のモジュールを使う場合はともかく、
+	自分達で書くモジュールでの
+	”深い”継承はできるだけ避けたい。
+	何でも深くすればよいというものではないでしょう。 
+
+	</para>
+	</listitem>
+
+</itemizedlist>
+</para>
+
+
+<para>
+	libexec/ や libkern.pl にある関数は、
+	main:: に記述される部分は基本的なフローを記述している。
+	これらは基本的な枠組を示すものであるため、
+	 $CurProc (C でいえば struct *curproc にあたるもの)
+	を受け渡す、構造化プログラミング的な書き方をしている。
+</para>
+
+
+
+<para>
+	しかし、そのひとつ下の層、そしてさらにその下では、
+	再利用性とポリモーフィズムに傾いた方がよさそうにおもえる。
+</para>
+
+</sect1>
+
+</chapter>