I want to put down some notes on possible directions for this thinobject implementation. In general, the changes described here should have only internal impact, and should not greatly affect the system api. Rather, the idea is to progress by cleaning up some of the initial quick & dirty steps taken. In the process, hopefully we'll arrive at a leaner, simpler, and otherwise improved system.
I guess a big change would be to start moving built-in methods out of the thinobject enabler, and aim toward a cleaner executable. Method dispatch should just fall right through to the Object class, and so that would be the right place to put methods which apply to any object.
To get started, a default method might be defined there, so Object.default, with the task of issuing a message that no method was found, or perhaps to handle the auto-accessors for list and dict properties.
Each of the now built-in methods can be moved out individually, an replaced with a script or other executable in the Object store.
At some point the overall ownership and permissions of these classes and methods should be considered and appropriate adjustments made. Currently everything is probably owned just by my ordinary user, but it should really be either root or nobody, or something...
Security implications should be considered for the overall system, and a better idea of how to implement the system with various different "levels" of ownership... That is, to support class libraries in /usr/lib/, /usr/local/lib/, and $USER/lib/, etc..
A side issue is a desire to transition toward python for at least parts of the system, and so the need for a thinobject library for that language.
A useful application class might be developed to host objects in a gui mode on a workstation, and perhaps another class to support ajax or other net- and/or web-interactive interfaces. If this sort of thing can be done generically, it will leverage the entire system greatly.
The version issue needs to be figured out. I've tried a couple of simple approaches to store assumed class version metadata in an object, but this needs improvement. The first attempt simply stores a version attribute in the object, but this ignores the possibility of applying versioning to different classes in the object class hierarchy. That notion suggests using a dictionary of some sort, perhaps the default dictionary, %.
A key goal of the thinobject scheme is to keep the system as dumb as possible, with the least amount of coupling or broad definition of conventions. Because of this, I do NOT want to define a %VERSION property, since we'd be stepping into the realm of namespaces, and that's one thing I want to leave to applications.
Another aspect of versioning is the possibility of retaining support for older versions of classes, vs the simpler approach of just raising a flag and requiring an object to be upgraded to a later version. This would imply perhaps keeping older class versions on hand, e.g,. perhaps in a subdirectory under the class store, or maybe using prefixes of some sort. A simple approach might be to just store the version directly in the class link itself, but again, this only makes it possible for an object to identify its direct parent's version, and not the version of its subclasses. It might be best to think of versions to be orthoganol to the classes themselves; the dispatcher resolves the class directories through the symlinks (or whatever means is used), but then can (optionally?) fine-tune resolution using version metadata.
It might make sense to provide methods to support such upgrades, perhaps just using the new method in some way. Note that such an operation would necessarily change the object state, perhaps defining new data structures in the object or discarding ones no longer needed, but at least by storing the version information in the object.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I want to put down some notes on possible directions for this thinobject implementation. In general, the changes described here should have only internal impact, and should not greatly affect the system api. Rather, the idea is to progress by cleaning up some of the initial quick & dirty steps taken. In the process, hopefully we'll arrive at a leaner, simpler, and otherwise improved system.
I guess a big change would be to start moving built-in methods out of the thinobject enabler, and aim toward a cleaner executable. Method dispatch should just fall right through to the Object class, and so that would be the right place to put methods which apply to any object.
To get started, a default method might be defined there, so Object.default, with the task of issuing a message that no method was found, or perhaps to handle the auto-accessors for list and dict properties.
Each of the now built-in methods can be moved out individually, an replaced with a script or other executable in the Object store.
At some point the overall ownership and permissions of these classes and methods should be considered and appropriate adjustments made. Currently everything is probably owned just by my ordinary user, but it should really be either root or nobody, or something...
Security implications should be considered for the overall system, and a better idea of how to implement the system with various different "levels" of ownership... That is, to support class libraries in /usr/lib/, /usr/local/lib/, and $USER/lib/, etc..
A side issue is a desire to transition toward python for at least parts of the system, and so the need for a thinobject library for that language.
A useful application class might be developed to host objects in a gui mode on a workstation, and perhaps another class to support ajax or other net- and/or web-interactive interfaces. If this sort of thing can be done generically, it will leverage the entire system greatly.
The version issue needs to be figured out. I've tried a couple of simple approaches to store assumed class version metadata in an object, but this needs improvement. The first attempt simply stores a version attribute in the object, but this ignores the possibility of applying versioning to different classes in the object class hierarchy. That notion suggests using a dictionary of some sort, perhaps the default dictionary, %.
A key goal of the thinobject scheme is to keep the system as dumb as possible, with the least amount of coupling or broad definition of conventions. Because of this, I do NOT want to define a %VERSION property, since we'd be stepping into the realm of namespaces, and that's one thing I want to leave to applications.
Another aspect of versioning is the possibility of retaining support for older versions of classes, vs the simpler approach of just raising a flag and requiring an object to be upgraded to a later version. This would imply perhaps keeping older class versions on hand, e.g,. perhaps in a subdirectory under the class store, or maybe using prefixes of some sort. A simple approach might be to just store the version directly in the class link itself, but again, this only makes it possible for an object to identify its direct parent's version, and not the version of its subclasses. It might be best to think of versions to be orthoganol to the classes themselves; the dispatcher resolves the class directories through the symlinks (or whatever means is used), but then can (optionally?) fine-tune resolution using version metadata.
It might make sense to provide methods to support such upgrades, perhaps just using the new method in some way. Note that such an operation would necessarily change the object state, perhaps defining new data structures in the object or discarding ones no longer needed, but at least by storing the version information in the object.