You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal is two-part because the use of extend ties in with the use of exact. We will see why below.
*1) struct.exact
At the moment, struct only validates loose objects; when there are more props than required, they're simply ignored. This is probably safe for most use-cases, but some times you might want a strict mode where additional props are disallowed.
The proposed API for this is: struct(S).exact(x) -> x is exact S
There will be no change in the type guard. At compile time, exact is similar to loose validation, because any x will always be accepted as input, and it's unsafe to use un-validated props either way. It's only a runtime change where exact fails if there were more props than expected.
Example
constMessage=struct({from: string,to: string,content: string});constx={ from, to, content };if(Message.exact(x)){// x is valid}consty={ from, to, content, isForward };if(Message.exact(y)){// y is not valid Message, since it has an unexpected prop `isForward`}
*2) struct.extend
Currently, extend is its own Higher Order Predicate. Its behaviour is such that it accepts a struct predicate as first param, and a struct as second param. The definition of the first struct is enforced at compile-time; you cannot extend from an arbitrary type (use and for that). x must satisfy both structs, while the second struct may not contradict the first; only extend it.
Problem
Because struct.exact as defined previously is also a predicate, extend will have to disallow exact structs as a parameter, because its runtime validation will fail before being extensible.
Because extend is very tied in to struct, moving it to a method makes extend and exact mutually exclusive. I'd also expect extend to be used as an extension of a previously defined struct, rather than inline definition like extend(struct(...), ...). Making it a method makes a lot of sense.
There are still some concerns to be worried about, namely deeply strict structs, like this one:
constMessageContent=struct({type: oneOf("html","markdown"),value: string}).exact;// notice that MessageContent has been exact-edconstMessage=struct({from: string,to: string,content: MessageContent,});
This check fails to behave as expected at runtime because MessageWithAttachment will always fail as the original struct's content is exacted. This could be solved by having a way to extract the non-exact predicate out of an exact predicate, but we're yet to decide whether implicitly un-exacting structs when extending them is the right way to go.
The text was updated successfully, but these errors were encountered:
This proposal is two-part because the use of
extend
ties in with the use ofexact
. We will see why below.*1) struct.exact
At the moment,
struct
only validates loose objects; when there are more props than required, they're simply ignored. This is probably safe for most use-cases, but some times you might want a strict mode where additional props are disallowed.The proposed API for this is:
struct(S).exact(x) -> x is exact S
There will be no change in the type guard. At compile time,
exact
is similar to loose validation, because anyx
will always be accepted as input, and it's unsafe to use un-validated props either way. It's only a runtime change whereexact
fails if there were more props than expected.Example
*2) struct.extend
Currently,
extend
is its own Higher Order Predicate. Its behaviour is such that it accepts a struct predicate as first param, and a struct as second param. The definition of the first struct is enforced at compile-time; you cannot extend from an arbitrary type (useand
for that).x
must satisfy both structs, while the second struct may not contradict the first; only extend it.Problem
Because
struct.exact
as defined previously is also a predicate,extend
will have to disallow exact structs as a parameter, because its runtime validation will fail before being extensible.Because
extend
is very tied in tostruct
, moving it to a method makesextend
andexact
mutually exclusive. I'd also expectextend
to be used as an extension of a previously defined struct, rather than inline definition likeextend(struct(...), ...)
. Making it a method makes a lot of sense.Example
Existing:
Proposed:
Unaddressed issues
There are still some concerns to be worried about, namely deeply strict structs, like this one:
Say
Message
is extended like so:This check fails to behave as expected at runtime because
MessageWithAttachment
will always fail as the original struct'scontent
isexact
ed. This could be solved by having a way to extract the non-exact predicate out of an exact predicate, but we're yet to decide whether implicitly un-exacting structs when extending them is the right way to go.The text was updated successfully, but these errors were encountered: