On 26/08/2024 11:32, Andreas Heigl wrote:
Hey folks.
Am 26.08.24 um 11:26 schrieb Bilge:
On 26/08/2024 10:03, Andreas Leathley wrote:
On 24.08.24 18:49, Bilge wrote:
For me there is another question. When using interfaces and classes,
default values can be introduced, like this:
interface CompressionInterface
{
public function compress(string $data, int $level): string;
}
class GzipCompression implements CompressionInterface
{
public function compress(string $data, int $level = 4): string
{
// do something
}
}
When I have the GzipCompression class, I would know there is a default
value for $level, but when using the interface there might or might not
be a default value, depending on the implementation. As far as I read
the RFC, using "default" when there is no default would lead to a
runtime exception, but there is no way of finding out if there is a
default if you do not already know. Being able to test that could be
useful, although I am not sure about the syntax for that. In the
example
when getting CompressionInterface, I might test for the existence of a
default value of $level and leave it at the default if there is a
default (maybe I know that some implementations have a default value,
others don't). One could test the specific implementation with
instanceof checks, but the advantage of "default" could be that you do
not need to know the implementation and could only adapt to possibly
defined default values.
Hi Andreas,
Thanks for this question; I find this super interesting because it's
something we haven't thought about yet. I must admit I completely
overlooked that, whilst an interface /can/ require implementers to
specify a default, in the case that they do not, it is still valid
for implementations to selectively elect to provide one. Therefore I
can append to your example the following case (I removed the `string`
return type for now):
class ZipCompression implements CompressionInterface
{
public function compress(string $data, int $level)
{
var_dump($level);
}
}
new GzipCompression()->compress('', default ?? 6);
new ZipCompression()->compress('', default ?? 6);
In this case, we get the following output:
int(4)
Fatal error: Uncaught ValueError: Cannot pass default to required
parameter 2 of ZipCompression::compress()
I would like to fix this if possible, because I think this should be
valid, with emphasis on /if possible/, because it may be
prohibitively complex. Will update later.
Cheers,
Bilge
I think I am missing something here. From my understanding we are
*either* coding against the interface and then it should not be
possible to use `default` at all as no default is set in the
interface. So the fatal error is totally valid for me.
*Or* we are coding against the actual implementations. Then it is
totally valid IMO that providing `default` when no default is set in
the concrete implementation of the function signature raises a fatal
error.
Hi Andreas,
Thanks so much for pointing this out. Your argument seems absolutely
correct to me, that this is an invalid polymorphic pattern, and as such,
I have stopped development of this feature. I still want to thank the
other Andreas (L) for raising it, and intend to add it to the possible
future scope in the RFC to provide an exception to permit `default` on
the LHS of null-coalesce. We did at least assess that such an exception
would be viable even if the development work would be disproportional to
the benefit, so it's worth noting that down.
Cheers,
Bilge
