the use of "has" could also suggest a friendlier complementary term than "define"...but so far I don't have any ideas that I haven't talked myself out of...though "that" would probably be the front-runner.
hasOnly
in addition to this adding a hasOnly could be added to verify that no fields exist beyond those that are provided in the keySet, so if the above were rewritten to use hasOnly then it would be equivalent to including a hasOnlyFieldsIn(['firstName', 'lastName']). In the (theoretical) builder syntax this would have to be handled either by some kind of pragma within the closure such as:
user ( hasOnlyFieldsListed() ) {
firstName(...
...
}
I'd lean towards the second since it seems more consistent...but either should also allow setting a global default with a solution to selectively choose the other option to accommodate either style of validation.
In the event the hasOnly style is preferred the builder syntax would be convenient to just list fields without validating them such as
user {
firstName
lastName
}
while the map syntax would require something as a value...presently the standard pass would work but some additional sugar would probably be desirable.
define
got abused after being adopted by using it to both define the current value and also the children (was easier than thinking of another name)has
is suggested to replace the latter use ofdefine
, which would result in something like:the use of "has" could also suggest a friendlier complementary term than "define"...but so far I don't have any ideas that I haven't talked myself out of...though "that" would probably be the front-runner.
hasOnly
in addition to this adding a
hasOnly
could be added to verify that no fields exist beyond those that are provided in the keySet, so if the above were rewritten to usehasOnly
then it would be equivalent to including ahasOnlyFieldsIn(['firstName', 'lastName'])
. In the (theoretical) builder syntax this would have to be handled either by some kind of pragma within the closure such as:or a a special check on the object like:
I'd lean towards the second since it seems more consistent...but either should also allow setting a global default with a solution to selectively choose the other option to accommodate either style of validation.
In the event the hasOnly style is preferred the builder syntax would be convenient to just list fields without validating them such as
while the map syntax would require something as a value...presently the standard
pass
would work but some additional sugar would probably be desirable.