I've had a couple of CS guys strongly suggest that strict type checking would be needed for my thinobject system to be minimally worthy of consideration. I think I've come with a way to do that. This scheme would be optional by method, and would impose no cost if not used.
Consider invoking a method on an object where another object is an argument, e.g.,
a.f b
Currently, method f needs to check the type of b explicitly, at least if it cares enough to check. It ought to check, or risk some kind of breakage.
The proposed scheme would be for f to require an option to say that the argument types have been checked, or equivalent, and in the absense of that option instead provide a "prototype" for its argument list and fail with a specific, unique exit value.
In this case, then, when the enabler invokes the method it then fails, but also provides (somehow...) information on the argument types, e.g.,
MyClass ...
The enabler catches this error, grabs the prototype information, and then resolves b to check that it is of the specified class (i.e., type). If the check(s) fail, the enabler can report an error message and fail. If it/they succeed, the method f is again invoked, but along with the special option, e.g., perhaps:
f --arguments-type-checked-ok a b
Method f sees this option, and then carries on as it normally would.
Currently I have imposed one special exit value in the system in order to implement calling super-class methods; this would be one more value.
Note, too, that this could be extended to do other things, such as invoke methods on argument objects:
a.f b.g
This has the burden of perhaps cloning b to avoid changing it, but should be doable. One example or test use case posed by one of the CS guys was something like:
image1.blend image2.darken
I think I could handle this use-case by this mechanism.
I'm excited about this and want to give it a go! ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I started implemented something similar to the previous scheme, ending up with the following:
* - method fails with special type-error value
* - enabler runs method again to get prototype string
* - enabler scans argument list against protype, maybe fails
* - enabler invokes method to actually do something
This involves invoking the method 3 times, first to get the type error value, second to get the prototype, third for real.
I then reconsidered this scheme, and realized that the goal could more easily be accomplished by just providing a method in the Object class. A method wishing to do type checking could just run that method.
By doing this check after the method's options are parsed there's no extra stuff in the arglist, and so the prototype does not need to be dynamically generated.
Now working on Object.scan-arguments to do this, with a --proto STRING option to specify a prototype to check arguments against. I'll probably also provide an option, --execute-ok or something to, say , run an argument such as a.foo under tob.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The simplest form of type-checking (or prototyping?) is to specifiy a thinobject class, but other forms are needed as well, e.g., to check for files or perhaps numbers, etc.
To achieve the former I added support for the option-like file test operators for bash, but this makes the facility rather tied in to bash in that regard, and offers no hope to check for numbers or patterns.
So the though occurs: what about having a pseudo class to do this? I'm not at all sure of what syntax to use, but consider...
I've had a couple of CS guys strongly suggest that strict type checking would be needed for my thinobject system to be minimally worthy of consideration. I think I've come with a way to do that. This scheme would be optional by method, and would impose no cost if not used.
Consider invoking a method on an object where another object is an argument, e.g.,
a.f b
Currently, method f needs to check the type of b explicitly, at least if it cares enough to check. It ought to check, or risk some kind of breakage.
The proposed scheme would be for f to require an option to say that the argument types have been checked, or equivalent, and in the absense of that option instead provide a "prototype" for its argument list and fail with a specific, unique exit value.
In this case, then, when the enabler invokes the method it then fails, but also provides (somehow...) information on the argument types, e.g.,
MyClass ...
The enabler catches this error, grabs the prototype information, and then resolves b to check that it is of the specified class (i.e., type). If the check(s) fail, the enabler can report an error message and fail. If it/they succeed, the method f is again invoked, but along with the special option, e.g., perhaps:
f --arguments-type-checked-ok a b
Method f sees this option, and then carries on as it normally would.
Currently I have imposed one special exit value in the system in order to implement calling super-class methods; this would be one more value.
Note, too, that this could be extended to do other things, such as invoke methods on argument objects:
a.f b.g
This has the burden of perhaps cloning b to avoid changing it, but should be doable. One example or test use case posed by one of the CS guys was something like:
image1.blend image2.darken
I think I could handle this use-case by this mechanism.
I'm excited about this and want to give it a go! ...
I started implemented something similar to the previous scheme, ending up with the following:
* - method fails with special type-error value
* - enabler runs method again to get prototype string
* - enabler scans argument list against protype, maybe fails
* - enabler invokes method to actually do something
This involves invoking the method 3 times, first to get the type error value, second to get the prototype, third for real.
I then reconsidered this scheme, and realized that the goal could more easily be accomplished by just providing a method in the Object class. A method wishing to do type checking could just run that method.
By doing this check after the method's options are parsed there's no extra stuff in the arglist, and so the prototype does not need to be dynamically generated.
Now working on Object.scan-arguments to do this, with a --proto STRING option to specify a prototype to check arguments against. I'll probably also provide an option, --execute-ok or something to, say , run an argument such as a.foo under tob.
The simplest form of type-checking (or prototyping?) is to specifiy a thinobject class, but other forms are needed as well, e.g., to check for files or perhaps numbers, etc.
To achieve the former I added support for the option-like file test operators for bash, but this makes the facility rather tied in to bash in that regard, and offers no hope to check for numbers or patterns.
So the though occurs: what about having a pseudo class to do this? I'm not at all sure of what syntax to use, but consider...
Object Faux:File:exists Faux:File:isadirectory Faux:Number
This might even open up the door to support imposing class behaviors on a non-thinobject object...