Thanks for putting this together. I like the idea of providing a type safe way to access request data. I'm a bit concerned with the number of methods we would be adding, and where we're adding them. While a trait makes it simple to compose this logic into components and controllers, I feel like we should be having this logic on the request itself. Perhaps we could use named parameters to help expand the existing getXyz methods to add casting.

$value = $this->request->getQuery('page', 1, as: 'int');

I think this interface could be more ergonomic, but is harder to have typing work out as PHP doesn't have a good way to narrow method return types. 🤔

@markstory Thanks for the good feedback ♥. We use that Trait in our work. Unfortunately, extending the ServerRequest itself outside of Cake is not possible, so we opted for using the Trait on Controllers instead. These methods are very popular :).

I have another idea. What do you think about it? (I wrote it quickly without any checking.)

/**
 * @method string|null getCookieString(string $key, string|null $default = null)
 * @method bool|null getCookieBool(string $key, bool|null $default = null)
 * @method int|null getCookieInt(string $key, int|null $default = null)
 * ...
 */
class ServerRequest implements ServerRequestInterface
{
    public function __call(string $name, array $params): mixed
    {
        if (str_starts_with($name, 'is')) {
            // ...
            return $this->is(...$params);
        } elseif (str_starts_with($name, 'getCookie')) {
            return $this->resolveAsType($name, $this->cookies, ...$params);
        } elseif (str_starts_with($name, 'getData')) {
            return $this->resolveAsType($name, $this->data ?? [], ...$params);
        } elseif (str_starts_with($name, 'getParam')) {
            return $this->resolveAsType($name, $this->params, ...$params);
        } elseif (str_starts_with($name, 'getQuery')) {
            return $this->resolveAsType($name, $this->query, ...$params);
        }
        throw new BadMethodCallException(sprintf('Method `%s()` does not exist.', $name));
    }

    private function resolveAsType(string $methodName, array|object $source, mixed ...$args): mixed
    {
        $asType = str_replace(['getCookie', 'getQuery', 'getParam', 'getData'], '', $methodName);
        $rawValue = Hash::get($source, $args[0], $args[1]);

        return match ($asType) {
            'String' => is_string($rawValue) ? $rawValue : null,
            'Int' => filter_var($rawValue, FILTER_VALIDATE_INT, FILTER_NULL_ON_FAILURE),
            'Bool' => $this->filterBool($rawValue),
            default => throw new BadMethodCallException(sprintf('Method `%s()` does not exist.', $methodName)),
        };
    }
}

@jozefgrencik That's an interesting approach. We had a related discussion in the core team and had another approach to consider as well:

namespace Cake\Utility;

function toInt(?mixed $value): ?int
{
}

Each type conversion would have a separate function that could be imported and used in both userland and framework code.

@markstory Nice. I like it.

I will create a new class with the toInt()/toBool.. functions in a separate PR, and then we will see how we proceed with this PR. Okay?

I will create a new class with the toInt()/toBool.. functions in a separate PR, and then we will see how we proceed with this PR. Okay?

Sounds great. Thank you 🙇

@markstory @ravage84 Hi guys, is there anything missing here from @jozefgrencik? or it can be merged.

@markstory @ravage84 Hi guys, is there anything missing here from @jozefgrencik? or it can be merged.

Hi. First, we need to resolve #17295, then we'll be able to continue. I'll take a look at the PR today. Thx.

This pull request is stale because it has been open 30 days with no activity. Remove the stale label or comment on this issue, or it will be closed in 15 days

Now that #17295 is merged I am happy to contribute to this branch to get it closer to done if @jozefgrencik doesn't mind.

@jamisonbryant
I'm glad to hear that you're willing to continue working on this PR! Your contributions are very welcome.

There are multiple approaches mentioned in the comments and I am not sure which solution is the best. Maybe the core-team should agree on the solution first.

So how do we proceed? Having more granular access similar to Symfony sure should be a useful addition to 5.next

I have attached a set of utility classes that I have created for my own CakePHP projects.
Feel free to integrate them into CakePHP if you want.
Every class has two static methods from() and tryFrom() which work similarly to the methods in \BackedEnum class

Cast2.zip

Example use case:

$intOrNull = IntCast::tryFrom($this->getRequest()->getQuery('test'));//returns int or null
$int = IntCast::from($this->getRequest()->getQuery('test'));//returns int or throws exception
$stringOrNull = StringCast::tryFrom($this->getRequest()->getQuery('test'));//returns string or null
$string = StringCast::from($this->getRequest()->getQuery('test'));//returns string or throws exception

I agree that instead of overloading the Request, this is the easier opt-in mechanism for now.
It would have been nice if there was a more native approach to it, but let's then maybe just go with these kind of utility methods as they are also more universally usable (other parts of the app).

I have reuploaded and replaced attachment in my previous post because StringCast was missing in previous zip

@jamisonbryant
Are you and others still interested in adding this to 5.2?

I am not sure if we ever solved the problem of static analyzers not being able to determine the "correct" return type of a given "function" going through the __call() flow path. After we merged #17295 our team has just been using those global functions wrapped around $this->request->getCookie() for example.

Last I remember I was researching something to do with complex PHPStan/Psalm annotations that enabled it to work out the proper return type, but it seemed much more difficult than just wrapping the mixed function in a "caster" and then you know the return type 100%.

IMO, no, this doesn't need to go into core. Unless we add all of the specific functions like getCookieAsInt() and utilize the global caster functions within. @markstory you were originally concerned about the # of methods, less so now or same?

... you were originally concerned about the # of methods, less so now or same?

I do think it is a lot of method surface area that isn't really necessary. We can already do

$userId = toInt($this->request->getCookie('userId'));

I'm not convinced that adding 14 methods is a significant win over what we have now.