Persistent shell objects

Names of object oriented languages need not to start with the letter J or
end with ++. Even Unix shells offer some rudimentary OO techniques. For
example, the PATH variable allows the user to specify a directory for his
own applications, which will be started in favour of applications from the
/usr-directory. In OO-speak, he automatically inherits the methods from
the sytem class and can overwrite them (without overwriting the files
contents). This article introduces some extensions to the shell, which
match definitions of OO more closely.

[Installation: fetch it from http://wt.xpilot.org/projects/shobj/,
 untar it with "tar -xzvf shobj-0.2.1.tgz -C $HOME" and
 set your path with "export PATH=$PATH:$HOME/.shobj".]

After the installation of the extension is finished, you have a new
command called shobj. It is mainly used to create new shell-objects
with the following syntax:

        shobj create object class

To play around with shobj instantly, a sample class called daemon
can be used. We will create an object called telnetd, which is deriven
from the deamon class:

        sh> shobj create telnetd daemon

sh> indicates the shell prompt. To create an object means to create a
special application, which is included in your PATH automatically. So
you can use newly created shell-objects just like any other command:

        sh> telnetd description "I'm too lazy to add one."
        sh> telnetd description      # without arguments
        I'm too lazy to add one.

Not very fancy, but you get the idea. Methods for an object are
specified as the first parameter. Methods are itself nothing more
than special applications, which are not included in the PATH,
but (only) accessible via the object. Example: the method
"description", which knows how to store information above the
object. You can have two objects of the same class without
conflicts. They maintain their own copy of the object-data, while
sharing the same code.

Because methods are applications, you can add them to the class
very easily. For traditional init-scripts, which are of the
form
        case $METHOD in
                start) ...
                stop)  ...
        ...

it is difficult to add a "method" from inside an installation-routine.
Because that would require to modify code, which is generally a
difficult task. Use "shobj add method_name class_name" to add
a new method to a class.

Another interesting feature is the cli-method, which is a shell
that provides all methods. Example:

        sh> telnetd cli
        telnetd cli> description
        I'm too lazy to add one.
        telnetd cli> quit
        sh>

This way all the methods are accessible as commands and are well-hidden
in their own namespace. With "telnetd objvar cli", you can even slip
into the cli of deeper objects.

The disadvantages of shell-objects are:
 
        * It is more complex to write a method, than to hack an
        existing init.d-script.
 
        * They are slower, because of filename checking and the
        overhead to execute other scripts.
 
        * Not all methods are as easy as start and stop. Actions
        like status do not follow any models among the family of
        daemons. However, this can be handled by creating methods,
        which are not deriven from the class. (The status method
        would point to a script in methods/..).
 
        * They store their data in ar-archives, which are not
        editable. However, just overwrite the objvar-Method,
        if you have a better solution...
 
        * The cli-mode does not recognize quoting yet.

Ian Wild told me there is a book with a similar name by C. Jones ("Unix Shell Objects") so I renamed my project into "persistent shell objects"
to keep both strategies distinguishable.
 
As far as I understand it yet, the main differences are:
 
        (1) The lifetime of an persistant shell object ends when you
        destroy it, not when the current shell exits (therefore the name).
 
        (2) With persistent shell objects, methods are seperate
        applications, only accessible via the object.