Am 17.10.2023 um 19:39 schrieb Daniil Gentili :
> I would like to submit an RFC (and related PR) to deprecate posix_times for
> PHP 8.4, removing it for PHP 9.
My question here would be: Is there sufficient reason to remove this function
and introduce a BC break, i.e. is the implementation code
Hi,
This is precisely why I'm planning to submit the RFC to make the change
in PHP 8.4, which is when the new JIT will be introduced.
Regards,
Daniil.
On 10/18/23 08:52, Christian Schneider wrote:
Am 17.10.2023 um 19:46 schrieb Daniil Gentili :
I would like to submit an RFC and PR to
Hi,
As listed in my original thread, I think that offering posix_times
without offering sysconf would be like offering a version of the
microtime function, which returns a value divided by a *undocumented and
unexposed divider that changes in each patch version of PHP*.
The main reason I
Am 17.10.2023 um 19:46 schrieb Daniil Gentili :
> I would like to submit an RFC and PR to change a few INI defaults for
> opcache, changing how JIT is disabled by default.
>
> Currently, JIT is disabled by default using the |opcache.jit_buffer_size=0|
> default, instead of |opcache.jit=0|.
>
>
On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
>
> On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson
> wrote:
>
> > > There is also a technique to make the return value `[$key => $value]`
> > instead of just a value, but this loses simplicity.
> >
> > Hmm, since the naming array_first and array_last
2023-10-17 21:39 GMT+02:00, Rowan Tommins :
> On 16/10/2023 15:08, Olle Härstedt wrote:
>> Hello internals,
>>
>> Was there a previous discussion about the pros/cons of adding only the
>> syntax needed for generics, but not the functionality? So static
>> analyzers could use it, instead of
On Wed, Oct 18, 2023 at 2:37 PM Pierre wrote:
> Le 18/10/2023 à 13:01, Alex Wells a écrit :
> > The community has just now decided on the PHPDoc syntax for generics,
> has
> > just started widely adopting them in packages and has just got
> first-party
> > support from PHPStorm. I doubt that
Hi
On 10/18/23 09:00, Christian Schneider wrote:
My question here would be: Is there sufficient reason to remove this function
and introduce a BC break, i.e. is the implementation code hard to maintain or
does the function cause security issues?
Unless that is the case I'd leave it unchanged
> This function signature can be accomplished by userland once we have
> `array_key_first()` and `array_first()`. It's much better to keep
> `array_first()` as simple as possible and let everyone build their own
> approach to go about it since we have so many approaches.
The goal wasn't
> I completely understand what you're saying and I don't disagree with the
> thought process. What I disagree with is your statement that you will always
> use array_first() together with array_key_first(). When talking about
> standard lists (indexed from 0 to upper-bound), array_first() is an
Le 18/10/2023 à 17:37, Robert Landers a écrit :
That is all I want whenever I think of Generics in PHP. The rest is
just complicated fluff in my humble opinion.
Where I respectfully disagree is about exactly this: you would
appreciate array, I would very much appreciate
On Wed, 18 Oct 2023 at 17:05, Robert Landers
wrote:
>
> This is simply not true, 0 is not always the first key in a list,
> especially after filtering it. Hence there is a need for this function
> in the first place.
Just to clarify this point: If 0 is not the first key, then it's not a list.
> > This is simply not true, 0 is not always the first key in a list,
> > especially after filtering it. Hence there is a need for this function
> > in the first place.
>
> Just to clarify this point: If 0 is not the first key, then it's not a list.
> After filtering a list, you get an array that
On Fri, 13 Oct 2023, Ilija Tovilo wrote:
> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo wrote:
> > https://wiki.php.net/rfc/rfc1867-non-post
>
> Thank you for the feedback so far. I made a handful of changes to the RFC.
…
> Let me know if you have any more feedback.
The only comment I would
On Wed, Oct 18, 2023 at 3:47 PM Deleu wrote:
>
> On Wed, Oct 18, 2023 at 4:14 AM Olle Härstedt
> wrote:
>
> > 2023-10-17 21:39 GMT+02:00, Rowan Tommins :
> > > On 16/10/2023 15:08, Olle Härstedt wrote:
> > >> Hello internals,
> > >>
> > >> Was there a previous discussion about the pros/cons of
On Wed, Oct 18, 2023 at 12:04 PM Robert Landers
wrote:
> > I completely understand what you're saying and I don't disagree with the
> thought process. What I disagree with is your statement that you will
> always use array_first() together with array_key_first(). When talking
> about standard
On Wed, 18 Oct 2023 at 17:47, Levi Morrison
wrote:
>
> I don't see how `array_is_list` is relevant to `array_first` and
> `array_last`. PHP arrays are ordered:
>
> $foo = [
> "first" => 1,
> "third" => 3,
> ];
>
> It would be perfectly fine to use `array_first` or
Hi Karoly,
Il 11/10/2023 17:03, Karoly Negyesi ha scritto:
Drupal has been using PDO for a long time now but as it doesn't have async
support, the project is adding a mysqli driver. A sticky point here is the
lack of support for named placeholders which are widely used in Drupal land
but mysqli
On Fri, 6 Oct 2023, Tim Düsterhus wrote:
> On 10/6/23 15:44, Ilija Tovilo wrote:
> > https://wiki.php.net/rfc/rfc1867-non-post
> >
>
> Regarding the cleanup of the files, perhaps the files could be read into a
> `php://temp` stream
>
On Tue, Oct 17, 2023 at 8:46 PM Daniil Gentili wrote:
> Hello,
>
> I would like to submit an RFC and PR to change a few INI defaults for
> opcache, changing how JIT is disabled by default.
>
> Currently, JIT is disabled by default using the
> |opcache.jit_buffer_size=0| default, instead of
On Wed, Oct 18, 2023 at 4:31 AM Robert Landers
wrote:
> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
> >
> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson
> > wrote:
> >
> > > > There is also a technique to make the return value `[$key => $value]`
> > > instead of just a value, but this
Hi
On 10/17/23 19:06, Daniil Gentili wrote:
Personally, I would have instead preferred the much cleaner approach of
making *all* anonymous classes final by default, (preferrably) without
offering the option to make them non-final.
However, I understand that this might be a little bit too
On Wed, Oct 18, 2023 at 1:43 PM Deleu wrote:
>
>
>
> On Wed, Oct 18, 2023 at 4:31 AM Robert Landers
> wrote:
>>
>> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
>> >
>> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson
>> > wrote:
>> >
>> > > > There is also a technique to make the return
Le 18/10/2023 à 14:50, someniatko a écrit :
Hi internals,
This approach allows combining
- no BC break - `~=` is a new syntax which is unavailable in older PHP
versions
- explicitly showing an intent that objects are compared using a custom
comparison, rather than standard PHP one
- allow to
On Wed, Oct 18, 2023 at 2:51 PM someniatko wrote:
>
> Hi internals,
>
> There is often a need to compare whether two objects are equal. For
> example, a popular [brick/money](https://packagist.org/packages/brick/money)
> library has a `Money` class, which has an `equals()` method. However, this
>
On Wed, Oct 18, 2023 at 10:29 AM Brandon Jackson
wrote:
> > You may be using them and be totally unaware that you are using them.
>
> Emphasis on that. Take promises for example. Anyone using libraries
> that incorporate promises either are using fibers or will likely be
> using them in the near
On Tue, Oct 17, 2023 at 10:40 PM Rowan Tommins
wrote:
Using the same syntax for type information that is guaranteed to be true
> (existing run-time checks) and type information that is "advisory only"
> (new checks for optional static analysis) means users can no longer have
> confidence in that
Le 18/10/2023 à 13:01, Alex Wells a écrit :
The community has just now decided on the PHPDoc syntax for generics, has
just started widely adopting them in packages and has just got first-party
support from PHPStorm. I doubt that migrating to yet another temporary
solution (one that still
> You may be using them and be totally unaware that you are using them.
Emphasis on that. Take promises for example. Anyone using libraries
that incorporate promises either are using fibers or will likely be
using them in the near future. And I'd say that one pattern is
probably used enough to be
Hi internals,
There is often a need to compare whether two objects are equal. For
example, a popular [brick/money](https://packagist.org/packages/brick/money)
library has a `Money` class, which has an `equals()` method. However, this
becomes tedious to implement such methods, when multiple nested
On Wed, Oct 18, 2023 at 4:14 AM Olle Härstedt
wrote:
> 2023-10-17 21:39 GMT+02:00, Rowan Tommins :
> > On 16/10/2023 15:08, Olle Härstedt wrote:
> >> Hello internals,
> >>
> >> Was there a previous discussion about the pros/cons of adding only the
> >> syntax needed for generics, but not the
Am 18.10.2023 um 10:42 schrieb Daniil Gentili :
> This is precisely why I'm planning to submit the RFC to make the change in
> PHP 8.4, which is when the new JIT will be introduced.
Ah, I missed that part, my bad. I'd suggest mentioning this in the RFC.
I also went back Dmitry's RFC and saw that
On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus wrote:
>
> Hi
>
> On 10/17/23 19:06, Daniil Gentili wrote:
> > Personally, I would have instead preferred the much cleaner approach of
> > making *all* anonymous classes final by default, (preferrably) without
> > offering the option to make them
Hi
On 10/17/23 19:39, Daniil Gentili wrote:
I would like to submit an RFC (and related PR) to deprecate posix_times
for PHP 8.4, removing it for PHP 9.
[…]
Waiting for feedback, kind regards,
This deprecation appears to be sufficiently simple that it can likely be
included in the bulk
On Wed, Oct 18, 2023 at 9:29 AM Robert Landers
wrote:
> On Wed, Oct 18, 2023 at 1:43 PM Deleu wrote:
> >
> >
> >
> > On Wed, Oct 18, 2023 at 4:31 AM Robert Landers
> wrote:
> >>
> >> On Wed, Oct 18, 2023 at 5:26 AM Deleu wrote:
> >> >
> >> > On Tue, Oct 17, 2023 at 3:43 PM Brandon Jackson <
>
On 18 October 2023 08:13:57 BST, "Olle Härstedt" wrote:
>
>Not sure readability is improved here compared to existing @template
>annotations. ;)
That's because readability isn't the problem I was suggesting it would solve.
As with attributes in general, the aim would be to have the core
Hi,
On Tue, Oct 17, 2023 at 6:39 PM Daniil Gentili wrote:
> Hi everyone,
>
> I would like to submit an RFC (and related PR) to deprecate posix_times
> for PHP 8.4, removing it for PHP 9.
>
The times() is defined by POSIX and I don't see a reason why it couldn't be
exposed even though there is
On Wed, Oct 18, 2023 at 10:11 AM Brandon Jackson
wrote:
>
> I get your desire to keep things simple, but IMO returning a value
> that does not conflict with possibly valid values or somehow indicates
> the value was not present is important, and should come before
> simplicity. Which likely
On Wed, Oct 18, 2023, at 12:35 PM, Robert Landers wrote:
> On Wed, Oct 18, 2023 at 2:26 PM Tim Düsterhus wrote:
>>
>> Hi
>>
>> On 10/17/23 19:06, Daniil Gentili wrote:
>> > Personally, I would have instead preferred the much cleaner approach of
>> > making *all* anonymous classes final by
On Wed, Oct 18, 2023, at 1:12 PM, Robert Landers wrote:
> On Wed, Oct 18, 2023 at 2:51 PM someniatko wrote:
>>
>> Hi internals,
>>
>> There is often a need to compare whether two objects are equal. For
>> example, a popular [brick/money](https://packagist.org/packages/brick/money)
>> library has
On Wed, Oct 18, 2023, at 11:01 AM, Alex Wells wrote:
> On Tue, Oct 17, 2023 at 10:40 PM Rowan Tommins
> wrote:
>
> Using the same syntax for type information that is guaranteed to be true
>> (existing run-time checks) and type information that is "advisory only"
>> (new checks for optional static
> The only portion in your email I disagree with is this ending. I believe
> there are enough use-cases where if the first value is "valid null" or
> "default null" it won't matter. The developer will treat them both the same.
> Perhaps you disagree with this and want to avoid ambiguity at all
> Sure in many use cases undefined and null can be equivalent, but there
> are other use cases and considering the fact that php does not have a
> user level "undefined" value. It should at least attempt to not be
> ambiguous when possible. Instead of being ambiguous by default,
> requiring the
On Wed, Oct 18, 2023 at 10:22 PM Jordan LeDoux wrote:
>
> On Wed, Oct 18, 2023 at 6:03 AM Pierre wrote:
>
> > Le 18/10/2023 à 14:50, someniatko a écrit :
> > > Hi internals,
> > >
> > > This approach allows combining
> > > - no BC break - `~=` is a new syntax which is unavailable in older PHP
>
On Wed, Oct 18, 2023 at 6:03 AM Pierre wrote:
> Le 18/10/2023 à 14:50, someniatko a écrit :
> > Hi internals,
> >
> > This approach allows combining
> > - no BC break - `~=` is a new syntax which is unavailable in older PHP
> > versions
> > - explicitly showing an intent that objects are
Hi
On 10/18/23 18:07, Derick Rethans wrote:
Regarding the cleanup of the files, perhaps the files could be read into a
`php://temp` stream
(https://www.php.net/manual/en/wrappers.php.php#wrappers.php.memory)?
I don't think that reading potentially large files into memory is a
great idea. It
I believe it's time to shift our focus away from backward compatibility
(BC) concerns in major versions. In my opinion, genuine operator
overloading is incomparable to the pseudo operator. I genuinely see the
operator overloads as an invaluable addition to PHP 9
Lanre
On 2023-10-18 6:50
On Wed, Oct 18, 2023 at 2:51 PM someniatko wrote:
> Hi internals,
>
> There is often a need to compare whether two objects are equal. For
> example, a popular [brick/money](
> https://packagist.org/packages/brick/money)
> library has a `Money` class, which has an `equals()` method. However, this
On Wed, Oct 18, 2023, at 3:37 PM, Deleu wrote:
> I believe my reservations have been registered, I would not like to have
> `array_first()` behave in a non-obvious way (i.e. involving array $key)
> because it's useful for Fibers users. I believe that writing your own
> wrapper that always returns
On Wed, Oct 18, 2023 at 2:05 PM Christian Schneider
wrote:
> Am 18.10.2023 um 18:42 schrieb Larry Garfield :
> > So the real question is: Would anyone who voted No on operator
> overloading before vote Yes on it if it used ~=, ~>, ~+, etc. instead?
>
> I confess that I'm not a fan of operator
On Wed, Oct 18, 2023 at 2:49 PM Brandon Jackson
wrote:
> > The only portion in your email I disagree with is this ending. I believe
> there are enough use-cases where if the first value is "valid null" or
> "default null" it won't matter. The developer will treat them both the
> same. Perhaps
Hi
On 10/18/23 18:42, Larry Garfield wrote:
Honestly I'm still on team operator-override. *Most* major languages have operator
overloading, and it doesn't seem to cause a problem. (According to my research, C++,
Kotlin, Swift, Rust, C#, Haskell, Python, and Ruby all have operator
Am 18.10.2023 um 18:42 schrieb Larry Garfield :
> So the real question is: Would anyone who voted No on operator overloading
> before vote Yes on it if it used ~=, ~>, ~+, etc. instead?
I confess that I'm not a fan of operator overloading for a language like PHP
but introducing new operators
On Wed, Oct 18, 2023 at 7:05 PM Christian Schneider
wrote:
>
> Am 18.10.2023 um 18:42 schrieb Larry Garfield :
> > So the real question is: Would anyone who voted No on operator overloading
> > before vote Yes on it if it used ~=, ~>, ~+, etc. instead?
>
> I confess that I'm not a fan of
On Fri, Oct 13, 2023, at 11:15 AM, Ilija Tovilo wrote:
> Hi everyone
>
> On Fri, Oct 6, 2023 at 3:44 PM Ilija Tovilo wrote:
>> https://wiki.php.net/rfc/rfc1867-non-post
>
> Thank you for the feedback so far. I made a handful of changes to the RFC.
>
> * The function is renamed to
Hi
On 10/15/23 05:48, Saki Takamachi wrote:
I came up with the idea of using a signature like array_filter(), and when a callback is passed,
"return the first/last element that matches the condition" and "return null if there
is no match."
This would be 'array_find()' and I would be in
56 matches
Mail list logo