broad views of the thinobject scheme

[Ken Irving]

I have several instances of thinobject systems in use now, but in some cases I've been cheating and editing the "hidden" object files directly.  Doing this out of a pragmatic need to do actual work, but it's giving me some perspective on the whole system, I think.

One thought is that my original scheme of pairing a visible "nominal" object with a hidden thinobject, e.g., file ob and directory .ob/, is needlessly restrictive.  It may be as useful to just have ob/ be a thinobject directly, w/o using a dot-name to "hide" it.  This is certainly the case, for instance, if the object is already tucked away in some location that's inherently "hidden" from user or application views, e.g., under /var/local/... something.

I've got a few nascent objects set up now (though with some cheating) something like the following:

    /var/local/CLASS/ob1
    /var/local/CLASS/.ob1/
    /var/local/CLASS/ob2
    /var/local/CLASS/.ob2/
    ...

with symlinks from a more visible location:

    /home/ken/web/APPDIR/ob1
    /home/ken/web/APPDIR/.ob1 -> /var/local/CLASS/.ob1/
    /home/ken/web/APPDIR/ob2
    /home/ken/web/APPDIR/.ob2 -> /var/local/CLASS/.ob2/

In this case, while the application visble objects maybe useful, and the hidden component justified, the underlying actual objects under the /var/ directory don't need to be hidden and, e.g., could be:

    /var/local/CLASS/ob1/
    /var/local/CLASS/ob2/
    ...

I'm pretty sure my current tob.sh and ThinObject.pm can already deal with this sort of thing.  Mostly, this represents a change from my original view of the whole scheme, from the more restrictive and probably arcane view to something more general.

Broadly, what this thinobject scheme really is is a way to define method search paths for objects using normal filesystem and OS facilities.  An object has a set of methods specific to it; an object method is simply an executable program, but a program that can be found only in the search-path defined for the object.   The object itself contains data, and can have an arbitrary organization of files and directories.

Anyway, just some thoughts...

[Ken Irving]

Along these same lines, considering the essence of this "scheme" is pretty much the use of the link to the class libraries containing methods, etc., a couple of points come to mind.

One is that it might be reasonable to "hide" the class-link, e.g., if the thinobject directory is not hidden.  It doesn't make any difference in the workings of the system, but might be a useful way to provide object-oriented behaviors to an otherwise normal-looking directory.  I might consider doing something like searching for a set of patterns, e.g., first looking for the link with no dot, then with a dot.  This would be cheap in any case, and easy to do.

The other thought, not really on the topic of "broad views" but something to consider, is my choice of terminology.  I haven't been entirely comfortable or satisfied with using SUPER as the name of the class link, but that's what I decided upon more or less arbitrarily.  For the object itself, I'm using "ISA" as the link name, and I think that makes some sense.  However, for class inheritence I think it might be better to go with something like "PARENT", or even "P", though that's admittedly pretty obtuse/obfuscated.

SUPER however doesn't seem to hold up as I develop the scheme.  This became clear when I created a "method" method to return a list of methods or a path to a specific method.  As is sensible in object-oriented systems, a method can be defined at any level in the class hierarchy and still be referred to using just the method name.  An overridden method then hides so-named methods in the parent classes, and so the prefix "SUPER" can be used to unambiguously refer to higher-level methods.  The disconnect with my use of "SUPER" as a class link name became clear when I was surprised to find an inherited method showing up as just "get", say, and not "SUPER::get", which would only be defined in the case of overridden methods.  This is the more sensible and conventional use of the term, and using it as the normal class link is just confusing the issue.

This seems like much ado about nothing, but it's the little nothings that add up, hopefully, to something in the end.

I'll post a few ideas about PARENT, etc., in another thread...