This chapter describes a few topics on programming technique. See FNF on FML.ORG programming style. It is ambiguous where "default" word in the variable name is proper. The left side of the naming string is expected to show large scale such as CLASS. Let us consider article related variables. We expect $article_* variables for them. It seems better to use CLASS_default_XXX syntax not default_XXX. It seems proper to use systematic naming convension. For it, we define base class or inheritence of naming syntax. Consider class names. For example, "mail" implies messsage/rfc822 format text. The input into fml system is a mail, outgoing one is a mail. The variable are sub class of "mail" object, so the name is unified as PREFIX_mail_ATTRIBUTE style. mail_XXX mail_default_XXX use_incoming_mail_XXX incoming_mail_XXX use_outgoing_mail_XXX outgoing_mail_XXX use_report_mail_XXX report_mail_XXX Other example (header): header_XXX header_default_XXX article_header_XXX use_article_header_XXX command_mail_header_XXX use_command_mail_header_XXX We can describe structure of class as follows: command { SOMETHING_command admin_command } directory { XXX_directory } file { template_file } mail { incoming_mail outgoing_mail report_mail } message { reply_message } article { article_digest (not use digest to show digest of article) article_spool (not use spool to show spool of article) } use_VARIABLE = yes or no # append _dir for directory. VARIABLE_dir = STRING # append _file for file. VARIABLE_file = STRING VARIABLE_type = STRING VARIABLE_format = STRING VARIABLE_format_type = STRING VARIABLE_limit = STRING (NUMBER but STRING) VARIABLE_upper_limit = STRING (NUMBER but STRING) VARIABLE_lower_limit = STRING (NUMBER but STRING) VARIABLE_restrictions = reject_ATTRIBUTE1 check_ATTRIBUTE2 permit_XXX ATTRIBUTE1 = PATTERN1 PATTERN2 ... ATTRIBUTE2 = var1 var2 PROGRAM_VARIABLE_ATTRIBUTE See also FNF on style. Apply quotemeta() for search key. Use access method for object not handle directly within objects. Example: To access to main.cf object, not use $curproc->{ ... }->{ main_cf } instead use $curproc->main_cf(); style. It is better not to use @EXPORT and @EXPORT_OK. How depth of classes is allowed ? two such as String::is_japanese_string() ? At least 3, I think. Here is the original idea log. We can use polymorphism in perl. Use it and object composition instaed of multiple inheritence. Perl 5's OOP is not OOP. Do not depent on it. It just provides simple use of variable since variable itself knows the home (object / package). Interface for re-use and abstraction should be OOP style. We want to use OOP style in using Perl 5 but take care for OOP-ism. Balance is important. not use deep inheritence. Programs in libexec/ describes the basic flow of processes. They may be allowd to be structured not object oriented programming Polymorphism and re-use is important especially in sub-classes.