Ken Irving - 2007-11-16

I've been working toward rolling out an application using the ThinObject backend, and in the process have worked on some basic aspects of the thinobject system itself.  One such aspect is a convention that each class should provide a 'help' method, and each method of that class support a --help option.  In order to get at those help screens, though, I needed to resolve superclass methods.

Thinobject methods are searched for along the class symlinks, and the first method of a given name found is accessible using just the name.  That method might override or subclass a so-named method in a parent class, and in that case the parent's methods are tagged with the prefix 'SUPER::'.  There may be several levels of this, and in fact, if the convention **every class provides a help method** is followed, there'll at least be a chain of help methods mapping to each class.

A view of this can be had using the 'method' method, with more detail visible via the 'find' method, e.g.:

    $ tob ob.method | grep help
    SUPER::SUPER::help
    SUPER::help
    help

    $ tob ob.find | grep help
    ^/^/help
    ^/^/^/^/help
    ^/^/^/help

The former shows the callable method names, while the latter shows the path to each method within the thinobject.

NOTE: It will probably be useful to augment the 'method' view to optionally show the class name.  To be done...

The change made to the enabler was to strip off each 'SUPER::' prefix, incrementing a counter each time, leaving only the nominal method name.  Then, during the method search, when the method is matched, the call is skipped if the counter is greater than zero, and the counter is decremented.  This allows making direct calls on the superclassed methods (which may or may not be a good thing to do!...), e.g.,

    $ tob ob.help

    $ tob ob.SUPER::SUPER::help

Similarly, if there's a superclassed method 'foo' which supports the --help option, the following should display those help screens:

    $ tob ob.foo --help

    $ tob ob.SUPER::foo --help

The question of whether it's ``OK'' for a user to directly call a superclassed method is perhaps not so simple.  The ThinObject system puts few restrictions on what methods actually do, and so it's up to the  application to determine this.  With this mechanism, however, the capability is there, put in the user's hands, so the question has to be addressed...

One possibility would be to tell the user: "don't do that", if it's not safe to call a superclassed method.  Or maybe there could be some additional means provided to make this throw an exception or something...  For now, in any case, the capability is there, period.

A quick look at superclassing might help a bit.  Given method 'foo' in a parent class, and a so-named method can choose to simply override the parent's version or it can do something and then invoke the parent's method.  In either case, calling SUPER::foo might mess with the object state, or it might be safe -- there's just no way for the ThinObject system to know this.

I can envision a mechanism for this, but do not intend to implement it at this point.  A class might define a special property to codify access to methods, perhaps something analogous to /etc/host.deny and /etc/host.allow of the inetd (etc.) system.    To be workable, such a solution would perhaps need to accomodate selective access, so that, e.g., maybe all 'help' methods could be called but no others, or methods could be called only with the --help option, etc..  So I think there's a reasonable possibility to flesh this out, and I'm not going to sweat the details at this point.