Probably the single key to this thinobject scheme is the link from an object to its class library directory, and the associated link from subclass to parent class. To date, I've used the term "ISA" for the former, "SUPER" for the latter, but I'm now planning to change these to something else.
First, though, a note on the nature of this link. I've implemented it as a symlink, a very convenient and powerful feature of some filesystems (standard on Linux) which allows a file to refer to some other file or directory. A symbolic link, as its name suggests, is a file which contains the name of the referent file.
The target of a symlink can be queried and operated on using OS supplied tools and utilities, and this makes it very easy to have an object or class refer directly to a parent class, or more specifically, to a directory containing a set of executable programs, the class methods.
As key as this link is to the workings of the thinobject system, the same ends could be met in other ways. In particular, an ordinary file could be used to store the name of the parent class. This would require an additional file-read to get the value, followed by openning the target directory for reading, but the end goals could still be met. Or, if a thinobject were to be implemented in a file as opposed to a directory, an entry in that file could contain the same textual reference to a remote class library or maybe an executable handler for the class, where all the methods are contained.
However, I'm using Linux, and there's no reason not to use available tools, so I'm sticking with symlinks.
The use of "ISA" as the name of the symbolic link is sensible enough, since an object can reasonably be thought of as an instance of the class. The same cannot be said for "SUPER", a term that is used in a related sense in other object-oriented languages, but which I think I've misused in this system.
The "correct", or at least conventional, use of "SUPER" is to explicitly identify an otherwise hidden version of an overridden method. Thus, if class A defines method m (i.e., A::m), and A is the parent of class B which also defines an m method, then the following methods should be available to objects of the B class:
<pre>
object::m
object::SUPER::m
</pre>
Further, this relationship applies regardless of the level or depth of the class hierarchy. If B is subclassed to class C and
beyond, but none of the subclasses override m, the same forms are used to refer to the two m methods.
On realizing this fact, it dawned on me that a better term than SUPER would be PARENT, in naming the class-to-class links. "PARENT" is explicit, sensible, and correct -- but it's just too long, too "big" for my tastes. Perhaps something like "P" or "_P" could be used, but these are perhaps too "ordinary", and might eventually get in the way of an application's need for its own use of files.
.... gotta run now, but will continue this later...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have changed the symlink-to-class name to "^" for both objects and classes, and intend to also support a dotted version. This has some interesting implications, since such a link can be dropped into an ordinary directory, rendering that directory as an object of the linked class.
To summarize some of the basic concepts and conventions, a file named "%" (and I should also add support for ".%" is to be read to initialize parameters for the object. There could also be a "@" or ".@" property file, but for the moment I don't have a use for it.
The "%" file is assumed to contain lines of the form "tag=value", with whitespace allowed. So far I impose/assume no additional structure in the
file, but that could be done, whether using a pythonesque scheme or some other means. I do want to try to keep things simple, ... or "thin"...
The "%" file can use indirection, identifying a @-prefixed file as a property, e.g.,
In general, the "%" file should not be written to by automated methods; it should be user-editable as a "config" file for the object. Any "%" files defined in parent classes will also be read, such that the object and any subclass parameters override so-named parameters defined further toward the root of the class tree.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Probably the single key to this thinobject scheme is the link from an object to its class library directory, and the associated link from subclass to parent class. To date, I've used the term "ISA" for the former, "SUPER" for the latter, but I'm now planning to change these to something else.
First, though, a note on the nature of this link. I've implemented it as a symlink, a very convenient and powerful feature of some filesystems (standard on Linux) which allows a file to refer to some other file or directory. A symbolic link, as its name suggests, is a file which contains the name of the referent file.
The target of a symlink can be queried and operated on using OS supplied tools and utilities, and this makes it very easy to have an object or class refer directly to a parent class, or more specifically, to a directory containing a set of executable programs, the class methods.
As key as this link is to the workings of the thinobject system, the same ends could be met in other ways. In particular, an ordinary file could be used to store the name of the parent class. This would require an additional file-read to get the value, followed by openning the target directory for reading, but the end goals could still be met. Or, if a thinobject were to be implemented in a file as opposed to a directory, an entry in that file could contain the same textual reference to a remote class library or maybe an executable handler for the class, where all the methods are contained.
However, I'm using Linux, and there's no reason not to use available tools, so I'm sticking with symlinks.
The use of "ISA" as the name of the symbolic link is sensible enough, since an object can reasonably be thought of as an instance of the class. The same cannot be said for "SUPER", a term that is used in a related sense in other object-oriented languages, but which I think I've misused in this system.
The "correct", or at least conventional, use of "SUPER" is to explicitly identify an otherwise hidden version of an overridden method. Thus, if class A defines method m (i.e., A::m), and A is the parent of class B which also defines an m method, then the following methods should be available to objects of the B class:
<pre>
object::m
object::SUPER::m
</pre>
Further, this relationship applies regardless of the level or depth of the class hierarchy. If B is subclassed to class C and
beyond, but none of the subclasses override m, the same forms are used to refer to the two m methods.
On realizing this fact, it dawned on me that a better term than SUPER would be PARENT, in naming the class-to-class links. "PARENT" is explicit, sensible, and correct -- but it's just too long, too "big" for my tastes. Perhaps something like "P" or "_P" could be used, but these are perhaps too "ordinary", and might eventually get in the way of an application's need for its own use of files.
.... gotta run now, but will continue this later...
I have changed the symlink-to-class name to "^" for both objects and classes, and intend to also support a dotted version. This has some interesting implications, since such a link can be dropped into an ordinary directory, rendering that directory as an object of the linked class.
To summarize some of the basic concepts and conventions, a file named "%" (and I should also add support for ".%" is to be read to initialize parameters for the object. There could also be a "@" or ".@" property file, but for the moment I don't have a use for it.
The "%" file is assumed to contain lines of the form "tag=value", with whitespace allowed. So far I impose/assume no additional structure in the
file, but that could be done, whether using a pythonesque scheme or some other means. I do want to try to keep things simple, ... or "thin"...
The "%" file can use indirection, identifying a @-prefixed file as a property, e.g.,
<pre>
animal = dog
name = @name
</pre>
In general, the "%" file should not be written to by automated methods; it should be user-editable as a "config" file for the object. Any "%" files defined in parent classes will also be read, such that the object and any subclass parameters override so-named parameters defined further toward the root of the class tree.