A brief introduction to thinobject...
What is it?
thinobject is an attempt to realize an object-oriented system on a
standard (*nix) filesystem, making use of ordinary files, directories,
and symbolic links, along with a set of conventions and a few tools.
Why bother?
thinobject is my attempt to scratch the itch of managing data and
behaviors on those data.
Does it work?
I've had no (or little) outside comments or analysis, but from my
decidedly non-object viewpoint it seems to work, and really pretty
well.
What makes it work?
Besides the conventions embedded in the scheme, a shell script in
the user's path, named thinob or tob, actually enables the system
to work. That script, which I refer to as the ``enabler'', parses
its command line to change:
object.method arguments
to:
method object arguments
It does that by semantically parsing object.method at the last dot,
and then working to resolve object to a ``thinobject'' by following
symlinks and looking in dotted names, and then working to resolve
method by looking in a class link, named ^, stored in the object
directory, then looking in ^/^/ and so on.
Do any OO or OOP buzzwords apply?
I'm not an expert at OO programming in many languages, but have used
OO ideas and techniques for years in a few languages, including on
some decidedly non-OO platforms. I feel justified in saying that
thinobject can do:
inheritance
polymorphism
encapsulation
and probably other such things. And perhaps surprisingly, it actually
does them quite well.
Any caveats?
Well, sure, plenty. First, thinobject is largely based on convention,
and it doesn't make any great attempt to enforce those conventions, though
it does try to to some extent. Someone might be able to break the system
if they don't follow the conventions, whether deliberately or by accident.
But if you're willing to play by the rules, I think it can work.
What's the big advantage?
The main advantage is that it is based on ordinary files and directories
existing on the filesystem, including using ordinary executable programs
for methods. That last point means that methods can be written in any
language, so long as they adhere to a small minimal set of conventions,
the main one being to expect the object as the first argument.
But how does it *really* work?
Ok, the meat and potatoes of thinobject is that, instead of using the
normal shell PATH variable to resolve programs to execute, the object's
class link takes the place of PATH. Methods are resolved by looking in
^/ and then ^/^/, ^/^/^/ and so on until a match is found for the target
method.
Isn't that a kludge?
Oh, sure, but that's how it is. It's better now than before, when I
was using ISA and SUPER for the name of the class links...
What isn't thinobject?
It's not a fully developed language or OO environment developed by a
CS major or a young, smart bunch of brainy kids.
Your software project management skills suck!
Yeah... sorry. I try to do what I can, but tend to do what's easiest...
How could thinobject suck less?
Maybe if I could get some help organizing things, if someone who actually
knows how to do stuff -- like setting up source management systems, making
a working thinobject.org site, and so on -- were to get interested, then
maybe some progress could be made. Or I could try to get more clueful
myself (yeah, right).
What about those nasty special characters in filesnames?
I've tried to keep that sort of thing to a minimum, but I've taken advantage
of what __seems to work__ on my normal bash-powered xterms and debian linux
platforms. Here's the full list of special characters currently in use:
^ -- a class link, i.e., points to a thinobject class directory
@ -- a list property, i.e., a file where each line is an entry
% -- a dictionary (hash) property, i.e., a file of tag=value lines
Is thinobject compatible with other (non-Linux) platforms?
I have no idea, and to some extent, couldn't care less. I haven't done
tried to deploy or test this scheme on other systems, not Windows,
not Macs, not Sun or other *nixes, on and on. I need something that
works for me, and I'm not using systems that I'm not using.
Is thinobjects a dead end, a waste of time?
Maybe, but again, it seems to be working for me, so I'm giving it a
whirl.
Any examples of thinobject in actual use?
I'm working on an application to manage data at my day job as a hapless
engineer/analyst working in an environmental research group, and using
thinobject as the backend for that system, called DataSite. Again, the
most I can claim is that it seems to be working. (That system is not at
all ready for public viewing, being barely up to supporting my use...)
So I guess the answer to the question is really "no", unless the sig-demo
below can count. That code needs the tob ``enabler'' to be present, but
in a plain if obfuscated manner does the following:
1 - creates a class directory
2 - sets a class link to the root or base class in that class
3 - creates a method file in the class directory
4 - makes the method executable
5 - creates a directory for a nascent thinobject
6 - sets a class link in the directory, making it a thinobject
7 - executes the method on the object
Ken
--
Ken Irving, fn...@ua..., http://sourceforge.net/projects/thinobject/
Hi=~/lib/thinob/Try/Hi; mkdir -p $Hi; ln -s /usr/local/lib/thinob $Hi/^
hi=$(tob Try/Hi.tob hi); echo -e '#!/bin/sh\nshift\necho Hello $*!'>$hi
chmod +x $hi; mkdir say; ln -s $Hi say/^; tob say.hi world
|
