But this leads to code that can't pass static inspections?

interface Joiner {
    public function join(array $array): string;
}

class WideJoiner implements Joiner {
    public function join($iterable): string {
        $array = is_array($iterable) ? $array :
iterable_to_array($iterable);

        return implode(", ", $array);
    }
}

function joinWith(Joiner $joiner, $iterable) {
    return $joiner->join($iterable); // <-- invalid argument ?
}

According to the Joiner abstraction, only array is accepted, and that's all
a static analysis tool can know about the $joiner argument in the
joinWith() function.

Being unable to pass static inspections is one thing, but this also makes
the code generally difficult to explain - there's a contract, Joiner, which
states that an array is required - to a person reading the joinWith()
function, that's all they can know about a Joiner instance; it isn't safe
for anybody to depend on a specific implementation of Joiner with a widened
argument-type, unless they read through the entire codebase and happen to
know about the WideJoiner implementation, but even then, someone using the
joinWith() function would also need to know which implementation of Joiner
is being passed, which seems to defeats the purpose of even having an
abstraction in the first place?


On Mon, Nov 21, 2016 at 10:39 AM, Niklas Keller <m...@kelunik.com> wrote:

> Morning Internals,
>
> I'd like to announce a RFC to allow omitting the type declarations for
> parameters in subclasses:
> https://wiki.php.net/rfc/parameter-no-type-variance
>
> PHP doesn't currently allow variance for parameters as checking these for
> compatibility isn't possible on compile time.
> This limitation is caused by autoloading and doesn't allow widening the
> accepted parameters.
>
> This RFC proposes to allow ommiting the type entirely in a subclass, as
> dropping all parameter constraints is
> always valid according to the LSP principle.
>
> We already allow return types being added in subclasses.
>
> Your feedback is welcome. :-)
>
> Regards, Niklas
>

Reply via email to