Closed blablabla1234678 closed 2 months ago
This is certainly wrong because merging happens in each step. For example we have 2 definitions:
{
o: {
type: "oo",
items: {
x: {type: "String"}
}
},
oo: {
type: "Object",
items: {
x: {length: [1, 255]}
}
}
}
First we step through the definitions to get to the native type: ["o", "oo", "Object"]
. After that we can start property processing and step through the definitions again: ["o.items.x", "oo.items.x"]
. As a nested result we should get ["x", [{type: "String"}, {length: [1, 255]}]]
. Now we can merge the nested result into ["x", {type: "String", length: [1,255]}]
. After this we can merge the result into {type: ["o", "oo", "Object"], items: {x: {type: "String", length: [1,255]}}}
. So merging happens after we processed the properties, not in each step. In this case it is obvious to do so, but in other cases where the nested property is an Object as well or there are nested types defined in multiple steps it is not obvious how to do it.
Okay. What if we have multiple type chains? One possible solution is allowing only a single chain. Another solution is using a logical operator for type check which is AND or OR, but usually it will be AND. If we choose this solution, then the native type or omega of the type chain must be the same for all chains. So for example it must be String for all 2 chains in the upper example. Another case can be not defining a type for the chain, just some properties like we did in the example.
I decided to allow only a single type chain which will result a simpler code. I allow not typed complementary properties as well.
Another question here whether type merging of the parent should happen before property merging or after it?
I decided to merge types before merging properties.
I decided to parse the documentation first and add an iterator as a second step to build a validator or a view. I close this.
Currently Object processing looks like this: