thinobject-discussion — general discussion regarding the thinobject system

[thinobject] intro

[Ken I. <fn...@ua...>]

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

[thinobject] mixins

[Ken I. <fn...@ua...>]

I haven't actually used Ruby, despite intentions to do so, mainly since
I can whip things up in Perl more easily and so am inclined to do that.
So I'm not that familiar with what ``mixins'' are or how they're used,
other than what I recall from reading some Ruby books and a bit of the
ruby discussion list, but I think I may be able to see how they might
relate to the thinobject scheme.

The thinobject 'enabler' script, tob or thinob, resolves methods by
following ^ links in objects and clases.  Directories in a class should
be ignored, since they would (possibly) represent subclasses of the
class but bear no significance to the class itself.

That flies in the face of what I was thinking, which was to somehow
specify, in addition to the ^ link to parent class, another link that
would be followed in the resolution phase.  Without knowing enough about
ruby mixins, I suspect that this would be similar.

The 'normal' class hierarchy (tree?) strictly follows the ^ links, and
so a method might be resolved under an object as ^/foo or ^/^/^/foo,
possibly both.  Mixins would provide an additional path to resolve a
method, i.e., when no method has been identified, before failing, so
that maybe something like ^/^/^mixin/bar could be found.

The convention implicit in that would be that a mixin class link would
identify the class (and be linked directly to it), but the name would 
begin with '^' and include the class name.

I can see that this is doable, and could implement it in thinb/tob.
But wait; there's more...  I vaguely recall that Ruby stipulates something
about mixins, possibly that resolution doesn't descend beyond the
immediate mixin class?  That seems unlikely, as an arbitrary class must
necessarily depend on its own class tree to provide all of its behaviors.

So I guess I ought to look into how Matz worked this out.  It's also
probably a good idea not to go adding features without a clear need,
and so far I haven't had a need to step out of normal class resolution.

Mixins are supposedly (to my limited knowledge) a limited form of
multiple inheritance.  Might they be useful?

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