Benchmark equals() functions
#268
Comments
|
At first, compared with equals
assertEquals
validateEquals
|
|
@samchon Heya, if you are going to setup some additional benchmarks for TypeBox, let's get the validation routines aligned. So from the documentation. // ALLOW SUPERFLUOUS PROPERTIES
TSON.assertType<T>(input); // throws exception
TSON.is<T>(input); // returns boolean value
TSON.validate<T>(input); // archives all errors
// DO NOT ALLOW SUPERFLUOUS PROPERTIES
TSON.equals<T>(input); // returns boolean value
TSON.assertEquals<T>(input); // throws exception
TSON.validateEquals<T>(input); // archives all errorsWould translate to the following logic per test. // ------------------------------------------------------------
is() // returns boolean value
(input) => UltimateUnion.Check(input)
// ------------------------------------------------------------
equals() // returns boolean value
(input) => UltimateUnion.Check(input)
// ------------------------------------------------------------
assertEquals() // throws exception
(input) => { if(!UltimateUnion.Check(input)) throw Error('invalid') }
// ------------------------------------------------------------
validate() // archives all errors
(input) => UltimateUnion.Check(input) ? [] : [...UltimateUnion.Errors(input)]
// ------------------------------------------------------------
validateEquals() // archives all errors
(input) => UltimateUnion.Check(input) ? [] : [...UltimateUnion.Errors(input)]Happy to setup two sets of schemas for |
export class TypeGuardError extends Error {
public readonly method: string;
public readonly path: string | undefined;
public readonly expected: string;
public readonly value: any;
}
Therefore your suggested code about those functions is not acceptable. If I accept that code, it is not measuring UltimateUnion.Errors(input).next().value // GET ONLY ONE |
|
What about ? (input) => { if(!UltimateUnion.Check(input)) throw Error(UltimateUnion.Errors(input).next().value.message) } |
|
I'm not measuring Please understand that it is measuring (input) => if (!TSON.is(input)) TSON.assertType(input);
(input) => if (!IoTsObjectRecursive.is(input)) IoTsObjectRecursive(input); |
|
TypeBox doesn't have an assert function, but if it did it would be. if(!UltimateUnion.Check(input)) throw Error(UltimateUnion.Errors(input).next().value.message)For reference, the type check implementation for Fastify's type provider https://github.com/fastify/fastify-type-provider-typebox/blob/main/index.ts#L23-L39 |
|
Then why the |
|
Errors are treated as an optional query one would runs "after" a validation failure. The |
|
You mean that I think there's not any problem. What's the problem? Why only |
How is it benefitting? TypeBox doesn't even have an Assert function :D We're having to implement one for the purposes of this test. Anyway, why would you run a relatively slow error reporting pass when you can so easily test for the existence of errors with |
|
The assert benchmark program is designed to measure error detection function. I repeat that if you add Please understand that in the assert benchmark program, none of other validator libraries are boosting up performance through |
But the I think the issue here is that As I say, if I was to implement a if(!T.Check(value)) throw Error(T.Errors(value).next().value.message)
// ^ detect ^ report |
|
I'll change assert benchmark program to really generate the type errored data and re-process it after you implement the |
Close #268 - refactored entire benchmark program for TypeBox
Special benchmark program for TypeBox (@sinclairzx81)
Those strict validation functions would be benchmarked:
equals()assertEquals()validateEquals()The text was updated successfully, but these errors were encountered: