Added @template-extends to solve Psalm issues

[driehle]

The issues came from a recent new release of laminas-stdlib, which introduced templates in AbstractOptions.

[Ocramius]

can we be more precise here? 🤔

[driehle]

It would need to be the supertype of all options stored in the container. Not sure if that's desirable? Talking about all affected containers, most options are string, but there's also bool and some other objects. I don't really see the point to use template types for AbstractOptions anyways, but that's obviously not me to decide. 😇

[Ocramius]

If you add ... to the array, you should be able to cover the whole supertype

[driehle]

Instructions unclear 🙈
Which array? 🤔

[Ocramius]

The template type to add here, in theory , is array{foo: bar, ...}

[driehle]

Maybe I am misunderstanding AbstractOptions somehow, but it's technically an iterable<string, TValue>. Therefore, the template TValue does not reflect the configuration array, as your snippet suggests, but rather is the type applicable to each option value. That's the reason why I am questioning the usefulness of the template as such.

Here, in this class, we have three options:

• resultCache as string
• sqlLogger as ?string
• types as array or mixed[], though this could probably easily made more specific using the syntax you suggested

Therefore, we could use @template-extends AbstractOptions<null|string|array>, but since the relation between different options (i.e. keys) and their types is not preserved, I don't see much advantage in doing so. What is the benefit of being able to inject an array as resultCache type-wise, if that's not an allowed value?