On Tuesday, 11 March 2025 at 16:37, Juris Evertovskis wrote:
> Hey,
>
> Just a headsup that I plan to start the vote in a couple of days. Please let
> me know if there are concerns that might affect your stance on this proposal.
>
> https://wiki.php.net/rfc/optional-interfaces
I will be voting
>
>> I would also personally prefer associated types: ... This at least lets you
>> ensure the "other point" is the same type in both functions, though
>> personally, I'd rather just have generics.
>
> I'd also like to have generics, but that isn't something I can implement
> myself. Associa
On Mon, Mar 10, 2025, at 2:05 PM, Daniel Scherzer wrote:
> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.com/php/php-src/pu
On 11/03/2025 11:54, Gina P. Banyard wrote:
It also means that we need to do *multiple* passes, on the same code path,
resulting in somewhat of a code churn and possibly not using a common
abstraction.
Considering that we didn't even have the time to properly remove some
deprecations from PHP
[responding to multiple people instead of spamming multiple emails, I hope
that is okay]
On Mon, Mar 10, 2025 at 12:38 PM Eugene Sidelnyk
wrote:
>
> Yet, do you think it's reasonable that "never" type should be used rather
> than "void"? From what I know, never - is a special type used whe
Hello!
In modern PHP, the garbage collector (GC) is not a mandatory component,
provided that the code is written without circular dependencies. As soon as
an object loses its last reference (i.e., its reference count reaches
zero), PHP immediately frees the resources. In this sense, you can think
>
> 2025年3月8日(土) 19:06 Niels Dossche :
> >
> > On 08/03/2025 03:30, youkidearitai wrote:
> > > Hi, Internals
> > >
> > > The add mb_levenshtein was end and declined.
> > > Vote result is one yes and 5 no.
> > >
> > > Thank you very much voting.
> > >
> > > By the way, This message is means add gra
> Hi internals,
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
At first signature seemed somewhat confusing to me, but now it makes
perfect sense.
Type-wise, about LSP, I find it logical that more concrete implementations
cou
On Fri, Mar 7, 2025, at 09:48, Edmond Dantes wrote:
>
> >
> > As far as I know, all current SAPIs follow one of two patterns:
> >
>
> It seems that my example, although taken from real life, is more of an
> anti-pattern. Let's take a real example that is not an anti-pattern.
>
> There is a B
Hi Daniel
On Mon, Mar 10, 2025 at 8:06 PM Daniel Scherzer
wrote:
>
> I'd like to start discussion on a new RFC about allowing `never` for
> parameter types when declaring a method.
>
> * RFC: https://wiki.php.net/rfc/never-parameters-v2
> * Implementation: https://github.com/php/php-src/pull/180
Hi Rob
On Mon, Mar 10, 2025 at 9:23 AM Rob Landers wrote:
>
> I’ve been trying to chase down a very subtle bug in 8.4 that only happens
> when OPcache is enabled (I'm trying to create a reproducer to file an actual
> bug). From what I can tell, OPcache doesn’t zero out cache slots, so
> occasi
Hi internals,
I'd like to start discussion on a new RFC about allowing `never` for
parameter types when declaring a method.
* RFC: https://wiki.php.net/rfc/never-parameters-v2
* Implementation: https://github.com/php/php-src/pull/18016
-Daniel
Hey,
Just a headsup that I plan to start the vote in a couple of days. Please let
me know if there are concerns that might affect your stance on this
proposal.
https://wiki.php.net/rfc/optional-interfaces
BR,
Juris
Am 11.03.2025 um 16:29 schrieb Christian Schneider :
> ...(if you want to be strict about warnings then just convert them to an
> exception, that's easy enough)...
Reading it back I maybe wasn't clear: I mean if you as an application developer
want to be strict then you can use an error handler
Am 11.03.2025 um 12:54 schrieb Gina P. Banyard :
> Taking the example of ext/pcntl again, if it were a standalone extension,
> having it follow semver is a way more reasonable proposition.
> Because we could just release 2 versions the same day, a x.y+1.0 introducing
> a warning, and a x+1.0.0 wh
On Tuesday, 11 March 2025 at 11:12, Rowan Tommins [IMSoP]
wrote:
>
> On 11 March 2025 10:20:52 GMT, Rob Landers rob@bottled.codes wrote:
>
> > Well, when you make it an exception, it usually gets upgraded/fixed faster
> > :)
>
>
> Not necessarily. When people see long lists of breaking chan
On 11/03/2025 06:32, Gina P. Banyard wrote:
And if not a ValueError then it should be an E_WARNING.
Raising a deprecation is frankly non-sensical.
Validation errors exist to inform the person programing that there is
an error with the call site that is preventable very easily.
If we start emitti
On 11 March 2025 10:20:52 GMT, Rob Landers wrote:
>Well, when you make it an exception, it usually gets upgraded/fixed faster :)
Not necessarily. When people see long lists of breaking changes in a release,
they may just put off upgrading / marking the library compatible.
I think we should
On Tue, Mar 11, 2025, at 10:07, Christian Schneider wrote:
> Am 11.03.2025 um 07:32 schrieb Gina P. Banyard :
> > On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
> >> I’d like to align on the approach to validating arguments for built-in
> >> functions (usually for flag inputs). Some ongoing
Am 11.03.2025 um 07:32 schrieb Gina P. Banyard :
> On Monday, 10 March 2025 at 23:07, Jorg Sowa wrote:
>> I’d like to align on the approach to validating arguments for built-in
>> functions (usually for flag inputs). Some ongoing discussions in PRs:
>> - https://github.com/php/php-src/pull/15647
Hello,
I’m also wondering when I see code examples in the RFC like:
$profit = [1, 4, 5]
|> loadMany(...)
|> fn(array $records) => array_map(makeWidget(...), $records)
|> fn(array $ws) => array_filter(isOnSale(...), $ws)
|> fn(array $ws) => array_map(sellWidget(...), $ws)
|> a
21 matches
Mail list logo
