Fixed final class usage - again impossible to extend functionality

[adambalint-srg]

Oh yeah, finally the package's new (not yet released) version will use interfaces for chains, so I can extend the functionality despite of final core chain classes.
Oh wait, no.

laminas-inputfilter/src/Input.php

Line 384 in 3c54077

assert($chain instanceof ValidatorChain);

So at some points of the package it won't work if I use a different chain (with the core interface). The Input factory supports the custom chain classes, but the code itself not. Is it planned to fix?

Some other places where the classes are fixed:

laminas-inputfilter/src/Input.php

Line 255 in 3c54077

assert(

laminas-inputfilter/src/Input.php

Line 267 in 3c54077

$targetValidatorChain instanceof ValidatorChain

laminas-inputfilter/src/Input.php

Line 350 in 3c54077

assert($chain instanceof ValidatorChain);

laminas-inputfilter/src/ArrayInput.php

Line 118 in 3c54077

assert($chain instanceof ValidatorChain);

laminas-inputfilter/src/FileInput.php

Line 179 in 3c54077

assert($chain instanceof ValidatorChain);

Why merge and getValidator method not added to the interface? With this the code really can support custom chain classes.
If you agree about it, I can help with PR.

[gsteel]

This is still very much work in progress - the type hints have all been updated to Filter|Validator ChainInterface, but the internals of the methods where used, still rely on concrete implementations.

Mostly this is about hacking error messages to support "empty" situations.

We should be able to drop all chain usage to the main use-case, which is $chain->isValid($whatever, $context) rather than all the introspection that goes on in the internals.
This is preferable to expanding the interface methods, which we can't do without breaking BC anyway.

[adambalint-srg]

@gsteel Thanks for the quick answer, then I'll still wait for this package, and try to follow changes in our applications

[jguittard]

The same logic goes for FileInput: the class is declared final, although ArrayInput is not. I'd really like to extend FileInput to propose a base64 decoding support of file upload.
Hopefully final declaration will be removed soon.

[gsteel]

@jguittard

Unlikely that any concrete inputs will become non-final for the next major. That's why we have InputInterface - Not ruling it out completely, but it should be easy to implement any of the shipped interfaces - this is not currently true for InputInterface because it is massive… It needs trimming back to the absolutely necessary methods.

With the file input, overriding the handler should suffice - and this is not currently possible AFAIK, so the extension point here is likely in the handler, or, perhaps building in native support in the PSR handler is necessary?

[jguittard]

@gsteel it's actually already implemented in a business project, in a complete rewrite of the input with just a shunt within the setValue method.

$value = $this->decodeValue($value);
$this->handler = $this->createHandler($value);
[...]

This way the initial value is a base64 encoded string, and the returned value is a PSR-7 UploadedFileInterface with the help of StreamFactoryInterface and UploadedFileFactoryInterface.
It shouldn't be that hard to inherit from FileInput, although internal logic should be kept private, I can agree on this. As I said, ArrayInput is not declared final, is it?