4 ms·
I've been thinking about this recently too, and I think this is an area which is ripe for a language feature. Currently we have 3 (ugly) options: 1: Validate
by powatom 14y ago
I've been thinking about this recently too, and I think this is an area which is ripe for a language feature.
Currently we have 3 (ugly) options:
1: Validate before method call (bad for obvious reasons)
2: Validate immediately within method (does the job, but looks ugly).
3: Add some kind of pre-processing via method annotations which will do the validation for you.
Wouldn't it be better if we could assert the validation requirements directly within the method definition?
For example:
public boolean doSomethingFor(10 > int iterations > 0)...
Obviously this isn't the most concise example, but I think it demonstrates the point. I guess the problem with this is it makes future changes to the preconditions confusing / difficult - depending upon how exactly this feature would end up being implemented. I'm imagining that this wouldn't interfere directly with the method signature, and would instead be turned into code much like the one in the example during compilation.
- Strilanc 14y agoI think it's a better idea, in some languages at least, to extend the signature to contain general preconditions and postconditions. public boolean doSomethingFor(int iterations) { // this is considered part of the semantic signature requires iterations > 0 && iterations < 10; // implementation ... } Putting it in the types is a good idea, but extremely complicated. You need full dependent types to make it work.