Rename Call() validator

[henriquemoody]

The name Call() is a bit cryptic to me, at least. Since we always use Call() for filtering, should we rename it to Filter() instead? I think it would make more sense.

[alganet]

Filtering is one use case. However, Call is as generic as Callback

Call, Callback and Lazy are related in the sense that they use a callback to change how validation happens:

• Callback: "The result of validation is the result of this callback"
• Lazy: "The real validator is the one returned by this callback"
• Call: "The input used is the one returned by this callback"

Here's a couple of examples:

v::call(
    static fn ($id) => $db->fetchUser($id),
    v::attributes()
)->assert(42);

v::call(
    static fn ($codeSnippet) => eval($codeSnippet),
    v::notBlank()
)->assert('return 123;');

We cannot know what the callback does. It could be filtering, or pre-processing, or doing external work required to shape the input into something that can be passed to another validator. In fact, it doesn't even need to use the input.

In this example, the main validation is key('coupom, but the validator also takes a detour to ensure the current day is christmas:

v::templated(
    'This promotion is only valid for christmas',
    v::call(
        static fn () => date('d-m'),
        v::equals('25-12')
    )->key('coupom', v::notBlank())
)->assert($promoSubscription);

Call opens a door for the user to do things that Respect\Validation can't. And it's indeed a cryptic door 😄It's a last-resort kind of validator, for things we can't predict or support.

I'm ok with renaming it, but I don't think "Filter" is the right name. I am also willing to expand its documentation to showcase its potential.

I would also be happy with another distinct Filter validator that does filtery things.

[alganet]

I think my use of Call to explain case-insensitiveness usage might have been misunderstood. I'm using it in this "last-resort" role, and that should not be the final solution for case sensitiveness.

What we really want is something like v::contains(v::identical()) and v::contains(v::equals()), consistent with how v::length() works, wrapping behavior in formalized validators. That, however, is not feasible for 3.0, and we needed to remove the awkward $identical parameters.

Therefore, I do not envision filtering input as the long-term solution for this kind of issue, and although Call can be used for this, it's not exclusively for this.

[henriquemoody]

It's not so much about your examples, just just how I see Call. Maybe the wording "filter" is not correct, maybe "transform/process" are better terms. This is how I see it:

• Call: "I want to use this callable to transform/process the input before evaluating it"
• Callback: "I want to evaluate the input using this callable"
• Lazy: "I want to use this callable to create a validador to evaluate the input"

It's very hard to name those, they're hard-code heavy-user stuff.

---

Edit: Asked Claude Opus 4.5: https://gist.github.com/henriquemoody/466b3eadc6576b9aee81fe41c2e9da56, but I have to probe it a bit more. Interesting ideas nonetheless

[alganet]

@henriquemoody it would be nice if you shared the whole prompt+response, or the AI link! I want to know what you asked Claude.

---

In our convention style, Transformed would fill better. Even allowing design space to introduce a more formal transforming mechanism later.

For example, we could evolve this API to:

use Transformation\TransformerFacade as t;

v::transformed(static fn... // equivalent to our current `Call`, an open door to chaos as last resort

v::transformed(t::uppercase(), v::... // a more formal solution to case sensitivity
v::transformed(t::translit('ASCII'), v::... // transliterate input to ASCII just for a single validation node
v::transformed(t::trim(), v:... // trim the input just for a single validation node

// signature sketch
function transformed(callable|Transformer $input, Validator $validator)

I don't like Claude's suggestion of LazyValidator. Dynamic sounds better.

[henriquemoody]

I used ClaudeCode, and it doesn't have a sharing link (laaaame!), it allowed me to copy the response in Markdown, that's how I got it.

My prompt was a bit lazy:

I'm having an issue with the name of 3 of my validators: Call, Callback, and Lazy.

They all deal with callables, but I use them in different scenarios:

Call: "I want to use this callable to transform/process the input before evaluating it"
Callback: "I want to evaluate the input using this callable"
Lazy: "I want to use this callable to create a validador to evaluate the input"

Check their implementation, and tell me which names you think are more suitable for each one of them based on what they do.

---

I also liked the Dynamic better as well, also liked the Pipe one, but I'm not so sure yet.

I like your idea of transformed(). If we rename Call now, we could add that in v3 without breaking BC, but we could also just keep Call for now, and implemente Transformmed in a MINOR version, which I think it's a bit better because of our timeline.

[henriquemoody]

More insights: https://gemini.google.com/share/f7b801209208

[henriquemoody]

After checking with some AIs, I'm inclined to do the following:

• Lazy -> Factory
• Callback -> Satisfies
• Call -> After

[alganet]

I like Factory, Satisfies and After. Those seem very reasonable.

[henriquemoody]

Closed by #1658