Re: [PHP-DEV] [VOTE] Interface Default Methods
> > Stop using `implements` at all and solely rely on `use`. > > My 0.02€ > > Cheers > > Andreas > A Trait is not part of the Type system, it's not type-hintable, it's not mockable, it's harder to do code review (a Trait was modified, what gets impacted?). A trait is just an "easy" way to copy/paste code while hiding away the code that is being copy/pasted. To be honest here, a Trait is something that I wouldn't miss if it was deprecated, although I know that's just wishful thinking. An interface default implementation on the other hand is extremely powerful and clear. If you're not happy with the default implementation, just write your own, otherwise less code to write and a better type system at the end. -- Marco Deleu
[PHP-DEV] [VOTE] PDO subclasses
Hello internals, I'm opening the vote for the 'PDO driver specific sub-classes' RFC: https://wiki.php.net/rfc/pdo_driver_specific_subclasses It will last for two weeks and end on 2023-07-17T17:00:00Z cheers Dan Ack -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
On Mon, Jul 3, 2023 at 2:54 AM Tim Düsterhus wrote: > > Hi > > On 7/3/23 02:11, Levi Morrison wrote: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > the past 6 days, and the feature freeze deadline is fast approaching > > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > > as usual. > > I'm not really sold on the proposal in the first place, but I find it > incredibly problematic that there were non-trivial changes to the RFC > text just 4 minutes before voting started and having the justification > "it will be easier to change if bad". > > Combined with the phrasing of the email I'm replying to, it looks like > this proposal is attempted to be forced into PHP 8.3 for some reason, > without fully thinking it through / without allowing an in-depth > discussion. This is probably going to bite in the longer term. > > Best regards > Tim Düsterhus > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > I suppose different people will think different things about what 'trivial' means, but the main changes were announced 6 days earlier on the mailing list, and there was no discussion about it all. I consider that to be fine. I also do not consider that to be hurried. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Vote] Deprecate functions with overloaded signatures
On Thu June 29, 2023 at 11:51 AM Theodore Brown wrote:
> On Tue, June 27, 2023, 6:33 Rowan Tommins wrote:
> > On 27/06/2023 02:25, Theodore Brown wrote:
> > > Currently the following code returns only the array keys that loosely
> > > equal null:
> > >
> > > array_keys($array, null)
> > >
> > > If the function is changed to a single signature with $filter_value
> > > defaulting to null (with an argument count check to preserve the above
> > > functionality), its behavior becomes a lot more surprising/unexpected. If
> > > a parameter defaults to null, as a user I don't expect the function to
> > > work differently when I explicitly pass the default value.
> >
> >
> > An alternative solution to this situation is to introduce a new dummy
> > value for such parameters, similar to how JavaScript uses the special
> > "Symbol" type to have keys that can't collide with any userland value.
> > In this context, this could be achieved with a single-value enum, i.e.:
> >
> > enum ArrayKeys { case IncludeAll; }
> >
> > function array_keys(array $array, mixed $filter_value =
> > ArrayKeys::IncludeAll, bool $strict = false): array {}
> >
> > That way, the optional parameter has a real default value, distinct from
> > any value the user might wish to filter by, including null, and full
> > compatibility is maintained with existing code.
>
> ...Note that currently there is a draft RFC to support objects in array keys.
> [1] If that feature is accepted, would it not be allowed to filter array keys
> by the `ArrayKeys::IncludeAll` enum value? That would also be
> surprising/unexpected.
I must have been really tired when I wrote the above paragraph, because I
forgot that the `filter_value` parameter matches against the value, not the key
(so the Object Keys in Arrays RFC has nothing to do with it).
But this makes using an enum as the default `filter_value` even more
problematic, since enums can already be used as array values and this would
prevent filtering an array to return keys for this value. I.e. the following
code would stop working: https://3v4l.org/5Br1a
So I still believe the overloaded array_keys signature should be deprecated for
consistency and to avoid confusing behavior.
Best regards,
Theodore
[1]: https://wiki.php.net/rfc/object_keys_in_arrays
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
pon., 3 lip 2023 o 14:26 Andreas Heigl napisał(a): > Hey Michał > > On 03.07.23 13:32, Michał Marcin Brzuchalski wrote: > > Hi Levi, > > > > pon., 3 lip 2023 o 02:11 Levi Morrison > napisał(a): > > > >> Chatter on the [Interface Default Methods RFC][1] has been quiet for > >> the past 6 days, and the feature freeze deadline is fast approaching > >> for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > >> as usual. > >> > >> Thanks to everyone who discussed weaknesses in the RFC during the > >> discussion phase. > >> > >>[1]: https://wiki.php.net/rfc/interface-default-methods > > > > > > I voted "yes", my personal use case waits for this feature. My use > > case example: > > > > https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b > > I've added two already possible solutions to that as comments. > > > > With interface default methods I'd no longer need traits that implement a > > single or in rare cases 2 methods that > > use their respective methods returning objects and iterate in Generator > > fashion over a paginated result set. > > This is not an issue if there is one implementation of the interface but > > when I decorate to apply some: > > * caching > > * logging > > * failover > > That requires that you are in control over both the interface AND the > implementation. In which case you probably do not need an interface and > the Trait would be enough (using `abstract public function` in traits > works after all) > > So you could even skip the implements part. > > As the interface should be designed specifically to be > implementation-agnostic, adding implementation to the interface is > counter-productive. > > Adding abstract methods to a trait and then just adding the traits is no > issue at all especially when you are in control of the interface AND the > implementation. > > When you are NOT in control of the interface... well, you can't expect > to have a default implementation and I am already looking forward to the > complaints that it is great to have a default implementation, but not > *that* one. > > There is a reason why the respective construct in Rust (which was > mentioned in the RFC) is called a Trait and not an Interface. > > So to decouple the contract from the implementation it is necessary that > no implementation is part of the contract. > > > > > then the trait has to be attached to every class besides that it has to > > exist which is an additional symbol here. > > Stop using `implements` at all and solely rely on `use`. > I use an interface for mocks in unit tests. A default interface method allows me to remove some traits which are not my favorite and I'd like to remove them all. Turning the interface into an abstract class adds an inheritance that I want to avoid. Given that, it true is that it is possible to solve the problem differently but not without side effects (either lack of contract or inheritance). Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hey Michał On 03.07.23 13:32, Michał Marcin Brzuchalski wrote: Hi Levi, pon., 3 lip 2023 o 02:11 Levi Morrison napisał(a): Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. Thanks to everyone who discussed weaknesses in the RFC during the discussion phase. [1]: https://wiki.php.net/rfc/interface-default-methods I voted "yes", my personal use case waits for this feature. My use case example: https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b I've added two already possible solutions to that as comments. With interface default methods I'd no longer need traits that implement a single or in rare cases 2 methods that use their respective methods returning objects and iterate in Generator fashion over a paginated result set. This is not an issue if there is one implementation of the interface but when I decorate to apply some: * caching * logging * failover That requires that you are in control over both the interface AND the implementation. In which case you probably do not need an interface and the Trait would be enough (using `abstract public function` in traits works after all) So you could even skip the implements part. As the interface should be designed specifically to be implementation-agnostic, adding implementation to the interface is counter-productive. Adding abstract methods to a trait and then just adding the traits is no issue at all especially when you are in control of the interface AND the implementation. When you are NOT in control of the interface... well, you can't expect to have a default implementation and I am already looking forward to the complaints that it is great to have a default implementation, but not *that* one. There is a reason why the respective construct in Rust (which was mentioned in the RFC) is called a Trait and not an Interface. So to decouple the contract from the implementation it is necessary that no implementation is part of the contract. then the trait has to be attached to every class besides that it has to exist which is an additional symbol here. Stop using `implements` at all and solely rely on `use`. My 0.02€ Cheers Andreas -- ,,, (o o) +-ooO-(_)-Ooo-+ | Andreas Heigl | | mailto:andr...@heigl.org N 50°22'59.5" E 08°23'58" | | https://andreas.heigl.org | +-+ | https://hei.gl/appointmentwithandreas | +-+ | GPG-Key: https://hei.gl/keyandreasheiglorg | +-+ OpenPGP_signature Description: OpenPGP digital signature
Re: [PHP-DEV] [VOTE] Interface Default Methods
pon., 3 lip 2023 o 13:50 Pierre napisał(a): > Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit : > > I voted "yes", my personal use case waits for this feature. My use > > case example: > > > > https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b > > > > With interface default methods I'd no longer need traits that implement a > > single or in rare cases 2 methods that > > use their respective methods returning objects and iterate in Generator > > fashion over a paginated result set. > > This is not an issue if there is one implementation of the interface but > > when I decorate to apply some: > > * caching > > * logging > > * failover > > > > then the trait has to be attached to every class besides that it has to > > exist which is an additional symbol here. > > > > Cheers, > > Michał Marcin Brzuchalski > > Please everyone yes to this ! > > I use Symfony daily, and the SomethingAwareInterface / > SomethingAwareTrait is very annoying, by having default method > implementations on interfaces, it would remove the use of having traits > at all. Everything would be much easier to read and write. > I agree, there are two interfaces that always require adding a trait in Symfony. These are NormalizerAwareInterface, DenormalizerAwareInterface They always require including NormalizerAwareTrait, DenormalizerAwareTrait. With this feature none of the above traits would no longer be required and the interface use would be less confusing. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [VOTE] Interface Default Methods
Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit : I voted "yes", my personal use case waits for this feature. My use case example: https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b With interface default methods I'd no longer need traits that implement a single or in rare cases 2 methods that use their respective methods returning objects and iterate in Generator fashion over a paginated result set. This is not an issue if there is one implementation of the interface but when I decorate to apply some: * caching * logging * failover then the trait has to be attached to every class besides that it has to exist which is an additional symbol here. Cheers, Michał Marcin Brzuchalski Please everyone yes to this ! I use Symfony daily, and the SomethingAwareInterface / SomethingAwareTrait is very annoying, by having default method implementations on interfaces, it would remove the use of having traits at all. Everything would be much easier to read and write. LoggerAwareInterface would no longer require us to use LoggerAwareTrait on every class, etc... This is kind of sugar candy I'd really love. Best regards, -- Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hi Andreas, pon., 3 lip 2023 o 06:33 Andreas Heigl napisał(a): > Am 03.07.23 um 02:11 schrieb Levi Morrison: > > Chatter on the [Interface Default Methods RFC][1] has been quiet for > > the past 6 days, and the feature freeze deadline is fast approaching > > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > > as usual. > > > > Thanks to everyone who discussed weaknesses in the RFC during the > > discussion phase. > > > >[1]: https://wiki.php.net/rfc/interface-default-methods > > > I've voted "no" on this RFC for one simple reason: > > For me an interface is about the abstraction of a contract. It defines > how different parts of code interact with one another without having to > know about the implementation. > > With this RFC we are adding implementation details to the abstraction. > > That requires knowledge about the implementation of different parts of > the code. Which we do not have when defining an interface. I disagree, look at the example I presented in my other response, one method can use another to provide a default method which you'd be including via trait in every implementing class because as it only uses another interface method. This means that you don't need to know anything about the implementation itself at all. You're free to use other interface methods and don't need any properties or implementation details. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hi Levi, pon., 3 lip 2023 o 02:11 Levi Morrison napisał(a): > Chatter on the [Interface Default Methods RFC][1] has been quiet for > the past 6 days, and the feature freeze deadline is fast approaching > for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks > as usual. > > Thanks to everyone who discussed weaknesses in the RFC during the > discussion phase. > > [1]: https://wiki.php.net/rfc/interface-default-methods I voted "yes", my personal use case waits for this feature. My use case example: https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b With interface default methods I'd no longer need traits that implement a single or in rare cases 2 methods that use their respective methods returning objects and iterate in Generator fashion over a paginated result set. This is not an issue if there is one implementation of the interface but when I decorate to apply some: * caching * logging * failover then the trait has to be attached to every class besides that it has to exist which is an additional symbol here. Cheers, Michał Marcin Brzuchalski
Re: [PHP-DEV] [VOTE] Interface Default Methods
Hi On 7/3/23 02:11, Levi Morrison wrote: Chatter on the [Interface Default Methods RFC][1] has been quiet for the past 6 days, and the feature freeze deadline is fast approaching for PHP 8.3, so I'm moving this to vote. It'll be open for two weeks as usual. I'm not really sold on the proposal in the first place, but I find it incredibly problematic that there were non-trivial changes to the RFC text just 4 minutes before voting started and having the justification "it will be easier to change if bad". Combined with the phrasing of the email I'm replying to, it looks like this proposal is attempted to be forced into PHP 8.3 for some reason, without fully thinking it through / without allowing an in-depth discussion. This is probably going to bite in the longer term. Best regards Tim Düsterhus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
