On 24 May 2025 14:11:57 BST, Rob Landers wrote:
>My only concern is how this would be handled in the class tables. Right now,
>\AlicesCalendar\Monolog\Logger and \BobsDocs\Monolog\Logger would be
>considered entirely different types -- as in, not compatible. So if
>AlicesCalendar returns a type
On Sat, May 24, 2025, at 22:28, Niels Dossche wrote:
> On 24/05/2025 21:24, Rob Landers wrote:
> >
> >
> > On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
> >> Hi
> >>
> >> In my opinion, the return type should not be nullable.
> >> Returning NULL when the platform (or PHP on that platform
On 24/05/2025 21:24, Rob Landers wrote:
>
>
> On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
>> Hi
>>
>> In my opinion, the return type should not be nullable.
>> Returning NULL when the platform (or PHP on that platform) doesn't support
>> getting this information is an anti-pattern.
>> I
On Sat, May 24, 2025, at 19:42, Niels Dossche wrote:
> Hi
>
> In my opinion, the return type should not be nullable.
> Returning NULL when the platform (or PHP on that platform) doesn't support
> getting this information is an anti-pattern.
> Instead, availability of the necessary functionality
On Sat, May 24, 2025, at 19:37, Daniel Kesselberg wrote:
> Hi everyone,
>
> I'm happy to share my first RFC :) It proposes adding a small function
> to retrieve the number of available processors; a feature that's
> commonly found in other programming languages and one that I believe
> would be
Hi
In my opinion, the return type should not be nullable.
Returning NULL when the platform (or PHP on that platform) doesn't support
getting this information is an anti-pattern.
Instead, availability of the necessary functionality should be checked at
configure time and the function should be ma
Hi everyone,
I'm happy to share my first RFC :) It proposes adding a small function
to retrieve the number of available processors; a feature that's
commonly found in other programming languages and one that I believe
would be a useful addition to PHP.
The related PR has already received a b
As far as I know, this is how array keys are designed and changing
array_keys wouldn't solve the problem. The key is converted to the
appropriate type during creation. Array keys are defined as string|int
and expecting the values to be either string or int is a programming
error. Static analysis to
Hi internals,
I propose adding a preserve_key_types parameter to array_keys() to address
issues caused by automatic conversion of string-numeric keys to integers.
Developer Experience Considerations
While PHP's automatic conversion of numeric string keys to integers is
documented behavior, real-w
On Sat, May 24, 2025, at 11:34, Rowan Tommins [IMSoP] wrote:
>
>
> Hi Michael,
>
> I'm going to skip over all the details about the autoloader for now, because
> I think they're going deep into implementation details, and I want to focus
> on the same top-level design as my previous email.
>
On 24 May 2025 10:08:46 BST, "马正强" wrote:
>Hello internals,
>
>I’d like to propose adding with as a full alias for the namespace-related
>use keyword in PHP.
...
> - Does this improvement warrant an RFC?
> - Are there objections to the concept or keyword choice?
It would certainly need an
Hi Michael,
I'm going to skip over all the details about the autoloader for now, because I
think they're going deep into implementation details, and I want to focus on
the same top-level design as my previous email.
On 23 May 2025 02:27:41 BST, Michael Morris wrote:
>Bobs docs needs an old
Hello internals,
I’d like to propose adding with as a full alias for the namespace-related
use keyword in PHP. This is a purely syntactic improvement aimed at:
1. Clarifying semantics: with better conveys "reference/borrow" intent
(e.g., with Foo\Bar vs. use Foo\Bar).
2. Reducing beginne
13 matches
Mail list logo
