> 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/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
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
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
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
> 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
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 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 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
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 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
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
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 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
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 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 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 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
>
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 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
> > 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
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, 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: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.
> 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
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
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 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
> 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
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 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
>
> 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
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
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
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
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
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
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
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
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 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
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
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
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
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 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
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
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
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
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
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|.
>
>
56 matches
Mail list logo
