Commit graph

4 commits

Author SHA1 Message Date
Henrique Moody
e6af762fe4
Rename "Validatable" to "Rule"
Besides the interface's name, everything already calls this type "Rule",
not "Validatable." This commit puts a stone on it and renames the
interface for better naming.
2024-12-05 19:32:14 +01:00
Henrique Moody
fefe905e0b
Include "__root__" when getting message as an array
When converting an object into an array, we exclude the message root
message from it. Since we're using a convention to template those
messages as an array, we could also use the same convention to return
those messages.

While working on it, I noticed that the name "__self__" wasn't
reflecting what that really meant, so I renamed it "__root__" because it
better reflects the meaning of those messages/templates.

Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
2024-03-25 22:38:19 +01:00
Henrique Moody
66faefd695
Remove previous validation engine
After many refactorings, no rules use the previous validation engine.
That means we can remove the unused code from the repository and switch
from the previous to the new validation engine everywhere.

This commit will also soft deprecate the methods "validate()", and
"check()" in all the rules and the "assert()" in all rules but the
Validator itself. That means using those methods will still be allowed,
but static analysis tools might complain.

This is a big step toward releasing the next major version, as the code
is pretty much the way it should be when I release the next version.
There's some documentation to be updated, and I would like to change the
behavior of a couple of rules.

Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
2024-03-25 12:28:25 +01:00
Henrique Moody
238f2d506a
Update validation engine
There are a few "problems" with the current engine:

- Allowing each rule to execute assert() and check() means duplication
  in some cases.

- Because we use exceptions to assert/check, we can only invert a
  validation (with Not) if there are errors. That means that we have
  limited granularity control.

- There is a lot of logic in the exceptions. That means that even after
  it throws an exception, something could still happen. We're stable on
  that front, but I want to simplify them. Besides, debugging exception
  code is painful because the stack trace does not go beyond the
  exception.

Apart from that, there are many limitations with templating, and working
that out in the current implementation makes it much harder.

These changes will improve the library in many aspects, but they will
also change the behavior and break backward compatibility. However,
that's a price I'm willing to pay for the improvements we'll have.

Signed-off-by: Henrique Moody <henriquemoody@gmail.com>
2024-02-22 16:54:44 +01:00