It would be useful in some cases to be able to operate on thinobject classes as if they are objects. This might be used to explore the contents of a particular class, and to perhaps edit property or parameter values defined in the class. On the other hand, some methods should not be allowed on classes, e.g., where an object state is assumed and possibly manipulated.
A particular need is to access ``help'' information for the class. One way to do this would be to define a dummy object of the class, and then refer calls to it, but this would obviate viewing/editing class properties.
I'm not sure where to go with this at this point. Currently, I've added a check for class_as_object() in the thinob ``enabler'', and have found this useful when used with such ``built-in'' methods as ls, find, wc, and so on. These methods operate on the class directory itself. Method resolution, however, begins with the special ^ symlink, so methods of the class are not directly executable.
It might seem a Bad Idea (tm) to allow *any* method call or manipulation of a class as if it were an object. But a key reason I want this for is to be able to subclass a particular class to define various parameters, which will then be defined for any instances (objects) of that class. For example, the TimeSeries class includes a TZOFS parameter to allow some timezone to be assumed, rather than always assuming UTC. A given organization, though, may always work in a particular time zone, and so it would be a nuisance and potential trouble source to have to define that parameter on each use. So, we might define a special class for the organization's use, i.e.,
One idea was to, say, include the class directory itself in the method search-path, but to insert ``--help'' as the first argument. But that would obviate the above (mis?)uses... Still, maybe that's the best approach to take. The previous parameter and edit method calls would then be handled like:
which should be harmless, making no changes to the ``class as object'' state.
This may be the best approach. The Our-TimeSeries class is a special case, and maybe it's sufficient to leave it to a knowledgable adminstrator or system manager to set and manipulated the parameters and such. End users can still override any of the parameters; for instance, TZOFS might be set to some other value if desired for any particular object.
The nature of the ThinObject scheme is that ordinary files and directories are used, and it is possible in any case to abuse or misuse those facilities.
One idea might be to leave it up to each method to decide whether to allow its use on a class vs an object. Within the method, a check could be made, and if the ``object'' is really a class, then it could exit with an error message to use the --help option, or maybe even call that option directly.
I'm not sure what direction to go with this...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It would be useful in some cases to be able to operate on thinobject classes as if they are objects. This might be used to explore the contents of a particular class, and to perhaps edit property or parameter values defined in the class. On the other hand, some methods should not be allowed on classes, e.g., where an object state is assumed and possibly manipulated.
A particular need is to access ``help'' information for the class. One way to do this would be to define a dummy object of the class, and then refer calls to it, but this would obviate viewing/editing class properties.
I'm not sure where to go with this at this point. Currently, I've added a check for class_as_object() in the thinob ``enabler'', and have found this useful when used with such ``built-in'' methods as ls, find, wc, and so on. These methods operate on the class directory itself. Method resolution, however, begins with the special ^ symlink, so methods of the class are not directly executable.
It might seem a Bad Idea (tm) to allow *any* method call or manipulation of a class as if it were an object. But a key reason I want this for is to be able to subclass a particular class to define various parameters, which will then be defined for any instances (objects) of that class. For example, the TimeSeries class includes a TZOFS parameter to allow some timezone to be assumed, rather than always assuming UTC. A given organization, though, may always work in a particular time zone, and so it would be a nuisance and potential trouble source to have to define that parameter on each use. So, we might define a special class for the organization's use, i.e.,
tob Our-TimeSeries.new TimeSeries
tob Our-TimeSeries.param TZOFS=-0900
tob Our-TimeSeries.edit %
On the other hand, the class should not be manipulated as an object; it should not have an object's state. The following should not work:
tob Our-TimeSeries.store ...
tob Our-TimeSeries.get ...
Instead, what I'd like (somehow) to achieve would be to be able to call the ``help'' screens of those methods, so this might be possible:
tob Our-TimeSeries.store --help
tob Our-TimeSeries.get --help
tob Our-TimeSeries.help
One idea was to, say, include the class directory itself in the method search-path, but to insert ``--help'' as the first argument. But that would obviate the above (mis?)uses... Still, maybe that's the best approach to take. The previous parameter and edit method calls would then be handled like:
tob Our-TimeSeries.param --help TZOFS=-0900
tob Our-TimeSeries.edit --help %
which should be harmless, making no changes to the ``class as object'' state.
This may be the best approach. The Our-TimeSeries class is a special case, and maybe it's sufficient to leave it to a knowledgable adminstrator or system manager to set and manipulated the parameters and such. End users can still override any of the parameters; for instance, TZOFS might be set to some other value if desired for any particular object.
The nature of the ThinObject scheme is that ordinary files and directories are used, and it is possible in any case to abuse or misuse those facilities.
One idea might be to leave it up to each method to decide whether to allow its use on a class vs an object. Within the method, a check could be made, and if the ``object'' is really a class, then it could exit with an error message to use the --help option, or maybe even call that option directly.
I'm not sure what direction to go with this...