Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125296
Message-ID: <b358ba96-f176-4704-b5bf-68b8b0f55ed1@scriptfusion.com>
Date: Mon, 26 Aug 2024 23:09:25 +0100
Precedence: bulk
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Default expression
To: internals@lists.php.net
References: <0c8ed5d6-5507-4c41-8d7f-05d14ba8aa4c@scriptfusion.com>
 <15301ee5-7964-4f0b-8804-a19f95f43152@gmx.net>
 <a5e8faf3-e3d7-41c0-98b2-0999ee7444bb@scriptfusion.com>
 <5c980153-228a-4544-8fb7-09a1c265ef14@heigl.org>
Content-Language: en-GB
In-Reply-To: <5c980153-228a-4544-8fb7-09a1c265ef14@heigl.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: bilge@scriptfusion.com (Bilge)

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