On Thu, Jun 15, 2023 at 3:37 PM Ilija Tovilo wrote:
> > I am moving my RFC for interface default methods to discussion:
> > https://wiki.php.net/rfc/interface-default-methods.
>
> The RFC doesn't mention default implementations for static methods.
> I'm not sure there's a use case but it might mak
Hi Tim,
On 15 June 2023 20:17:31 BST, "Tim Düsterhus" wrote:
>
>Agreed, this is not ideal to sell random_int() as the default choice for all
>things being equal. I've made an attempt for a more neutral / inclusive
>wording in https://github.com/php/doc-en/pull/2528.
In case it's a while befor
Hi Levi
> I am moving my RFC for interface default methods to discussion:
> https://wiki.php.net/rfc/interface-default-methods.
This or a similar concept makes sense to me. The proposal seems
similar to Swift protocol extensions, or Rust traits, with the
exception that function default implementa
> On Thursday, Jun 15, 2023 at 12:01 PM, Deleu (mailto:deleu...@gmail.com)> wrote:
>
> One can argue that this change might make it so that users start
> considering adding methods with default implementation as
> not-so-much-a-bc-break and do so without bumping a major version, in which
> case t
Hi
Thank you.
On 6/15/23 20:24, Rowan Tommins wrote:
Looping back to the beginning of my email: The recommended replacement
is random_int() which is available for years, but the "organic"
migration did not really work.
I think that's partly because, rightly or wrongly, random_int() is not
ge
On 15/06/2023 13:14, Tim Düsterhus wrote:
Looping back to the beginning of my email: The recommended replacement
is random_int() which is available for years, but the "organic"
migration did not really work.
I think that's partly because, rightly or wrongly, random_int() is not
generally vie
>
> I still believe this information should be added to the RFC as the risk
> of adding new methods to an interface which collide with existing
> methods in implementations of that interface is very real, though I
> agree with Deleu that this BC impact is not so much of the RFC, but of
> what can h
On Thu, Jun 15, 2023 at 9:16 AM Tim Düsterhus wrote:
>
> Hi
>
> On 6/15/23 17:08, Deleu wrote:
> > The feature may introduce a new way for *Users of PHP* to break BC with
> > *Other Users of PHP*. The language change itself has no impact on PHP code
> > written prior to the feature. The additional
> I still believe this information should be added to the RFC as the risk
> of adding new methods to an interface which collide with existing
> methods in implementations of that interface is very real, though I
> agree with Deleu that this BC impact is not so much of the RFC, but of
> what can hap
Hi
On 6/15/23 17:08, Deleu wrote:
The feature may introduce a new way for *Users of PHP* to break BC with
*Other Users of PHP*. The language change itself has no impact on PHP code
written prior to the feature. The additional note about how users may break
BC by using the feature would be a desc
I loved the proposal and I think this has the potential to be a huge
developer experience improvement, perhaps at least as great as property
constructor promotion and match().
Just a side note though, in the Backward Compatibility section, I would
think that only "None" should be declared. From th
On 27-4-2023 23:28, Máté Kocsis wrote:
Hi Internals,
As you have possibly already experienced, overloaded signatures cause
various smaller and bigger issues, while the concept is not natively
supported by PHP. That's why I drafted an RFC which intends to phase out
the majority of overloaded func
On 15-6-2023 9:18, Máté Kocsis wrote:
Hi everyone,
As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.
Therefore, we'll start the
On Thu, 1 Jun 2023 at 17:16, G. P. B. wrote:
> Hello internals,
>
> The vote for the Define proper semantics for range() function RFC is now
> open and will last for two weeks until the 15th of June 2023:
>
> https://wiki.php.net/rfc/proper-range-semantics
>
The vote has now ended with 20 votes
Hi
On 6/15/23 13:46, Rowan Tommins wrote:
While I agree with the logic of deprecating mt_rand() in general, I do
think it's too early to do so in 8.3. The Random extension is very new, and
To be clear: The recommended replacement for mt_rand() for the majority
of use cases / applications is r
On Thu, 15 Jun 2023 at 08:19, Máté Kocsis wrote:
> As there was no discussion and complaint for a long time, we would like to
> move forward with the RFC. We believe Go and Tim answered Nikita's doubts
> elaborately, so we should make the question decided during the vote.
>
While I agree with t
Hi everyone,
As there was no discussion and complaint for a long time, we would like to
move forward with the RFC. We believe Go and Tim answered Nikita's doubts
elaborately, so we should make the question decided during the vote.
Therefore, we'll start the vote on Monday, unless new problems eme
17 matches
Mail list logo
