On Tuesday 29 July 2025 09:12:13 (+02:00), Dmitry Derepko wrote:
> Hi, Internals!
>
> I want to have a unified function phpinfo() for any environment.
>
> Currently phpinfo works different in CLI and SAPI modes:
> - SAPI mode enforces the function print HTML tags
> - CLI mode enforces the
> Hello PHP Internals,
>
> I would like to propose a discussion regarding two current limitations in
> PHP's exception handling system that I believe could be addressed to
> improve flexibility and developer experience.
>
> A few years ago I found that a library printed error traces wrong.
> After
On Tue, 29 Jul 2025 at 01:53, Rob Landers wrote:
>
>
> On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote:
>
>
>
> On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote:
>
>
> On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote:
>
>
> Wouldn’t a better approach be to allow serializing/deserializing
>
On Mon, Jul 28, 2025 at 8:54 PM Kamil Tekiela wrote:
>
>
> On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote:
>
> IMHO the trace should be set by the engine
>
Agreed. It should and it should continue to do it.
> it should not be possible to overwrite the getTrace method.
>
>>
Disagree. Not all
On Mon, Jul 28, 2025, at 19:54, Kamil Tekiela wrote:
>
>
> On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote:
>>
>> On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote:
>>>
>>> Wouldn’t a better approach be to allow serializing/deserializing exceptions?
>>>
>>> — Rob
>>
>> It would look like
On 28/07/2025 16:32, Larry Garfield wrote:
Even without the precision loss question, such a function would be very useful when
parsing input data of unknown type (and thus is a string). "Can I cast this string
to an int to use with an int parameter without any loss" is currently not as simple
On 28/07/2025 16:27, Larry Garfield wrote:
(I actually have no idea what the original reason was for making so much of
Exceptions final.)
If you start with everything marked "final", you can relax it as needed.
For internal classes particularly, there can be implementation and
performance p
On Mon 28 Jul 2025, 20:50 Dmitry Derepko, wrote:
>
> On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote:
>
>>
>> Wouldn’t a better approach be to allow serializing/deserializing
>> exceptions?
>>
>> — Rob
>>
>
> It would look like another workaround to my case. Same as deserializing
> data into a
On Mon, Jul 28, 2025 at 3:44 PM Rokas Šleinius wrote:
>
> On Mon, 28 Jul 2025 at 15:16, Lynn wrote:
>
>>
>>
>> On Mon, Jul 28, 2025 at 1:50 PM Rokas Šleinius wrote:
>>
>>>
>>> On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus wrote:
>>>
Hi
Am 2025-07-28 11:41, schrieb Dmitry Derepko:
On Mon, Jul 28, 2025 at 3:26 PM Rob Landers wrote:
>
> Wouldn’t a better approach be to allow serializing/deserializing
> exceptions?
>
> — Rob
>
It would look like another workaround to my case. Same as deserializing
data into a class to write into a private property.
The simpler the better: ju
On Mon, Jul 28, 2025 at 1:17 PM Tim Düsterhus wrote:
> I'm afraid I don't quite understand what actual goal you intend to solve
> with the proposal. The description of your use case is very abstract,
> can you provide a real-world example of a use-case you want to enable?
>
> Best regards
> Tim D
On Mon, Jul 28, 2025, at 8:00 AM, Alexandre Daubois wrote:
> Le lun. 28 juil. 2025 à 12:14, Gina P. Banyard a écrit :
>> For naming, maybe the following pair of functions make sense?
>> - is_representable_as_int()
>
> Definitely, thank you for proposing. Having a pair of functions for
> bidirectio
On Mon, Jul 28, 2025, at 6:48 AM, Rokas Šleinius wrote:
> | real-world example of a use-case you want to enable
>
> Say I am implementing a job runner, I do its error handling, and I want
> to enrich the caught exception with additional helpful data for
> debugging. In this process I create a cu
Hi
Am 2025-07-28 15:35, schrieb Tim Düsterhus:
Similarly to my other email: This is false. 2**53 is exactly
representable as float. Every power of two (<= 1024) is.
Small correction: That should've read `<= 1023` (or `< 1024`).
Best regards
Tim Düsterhus
Hi
Am 2025-07-28 15:00, schrieb Alexandre Daubois:
is_representable_as_float(2**53); // false, precision loss when
casted to float
Similarly to my other email: This is false. 2**53 is exactly
representable as float. Every power of two (<= 1024) is.
is_representable_as_float("1e308");
Le lun. 28 juil. 2025 à 12:18, Claude Pache a écrit :
> This is not correct: 2**53 + 1 is perfectly “safe” (for 64-bit builds of
> PHP), see: https://3v4l.org/P939d
>
> The specific notion of “safe integer” as introduced in JavaScript makes sense
> only for numbers encoded using IEEE 754, which
Le lun. 28 juil. 2025 à 12:14, Gina P. Banyard a écrit :
> For naming, maybe the following pair of functions make sense?
> - is_representable_as_int()
Definitely, thank you for proposing. Having a pair of functions for
bidirectional transformations makes much more sense than a single
ambiguous fu
On Mon, 28 Jul 2025 at 15:16, Lynn wrote:
>
>
> On Mon, Jul 28, 2025 at 1:50 PM Rokas Šleinius wrote:
>
>>
>> On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus wrote:
>>
>>> Hi
>>>
>>> Am 2025-07-28 11:41, schrieb Dmitry Derepko:
>>> > A few years ago I found that a library printed error traces wrong
On Mon, Jul 28, 2025, at 11:41, Dmitry Derepko wrote:
> Hello PHP Internals,
>
> I would like to propose a discussion regarding two current limitations in
> PHP's exception handling system that I believe could be addressed to improve
> flexibility and developer experience.
>
> A few years ago
On Mon, Jul 28, 2025 at 1:50 PM Rokas Šleinius wrote:
>
> On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus wrote:
>
>> Hi
>>
>> Am 2025-07-28 11:41, schrieb Dmitry Derepko:
>> > A few years ago I found that a library printed error traces wrong.
>> > After a little research I found that there was a mi
Hi
Am 2025-07-28 13:48, schrieb Rokas Šleinius:
Say I am implementing a job runner, I do its error handling, and I want
to
enrich the caught exception with additional helpful data for debugging.
In
this process I create a custom exception MyJobHandlerException, but the
trace of the new excepti
On Mon, 28 Jul 2025 at 13:56, Tim Düsterhus wrote:
> Hi
>
> Am 2025-07-28 11:41, schrieb Dmitry Derepko:
> > A few years ago I found that a library printed error traces wrong.
> > After a little research I found that there was a mix of 3rd party
> > integration error + raised error around the cur
> Le 26 juil. 2025 à 18:13, Alexandre Daubois a
> écrit :
>
>>
>> I'm not sure if accepting floats in the same function makes sense. If the
>> question is "can this value safely be stored in a float?" and you give it a
>> float, then the answer is surely "yes". You have no way of knowing if
Hi
Am 2025-07-28 11:41, schrieb Dmitry Derepko:
A few years ago I found that a library printed error traces wrong.
After a little research I found that there was a mix of 3rd party
integration error + raised error around the current bridge
implementation
(http client).
There were several PHP
On Friday, 25 July 2025 at 14:43, Alexandre Daubois
wrote:
> Hello Internals,
>
> I would like to gather feedback on the proposal to add an
> "is_integer_safe()" function to PHP. The idea came to me while
> replying to a thread [1], but I think creating a discussion is more
> appropriate.
>
>
Hi
Am 2025-07-26 15:45, schrieb Rowan Tommins [IMSoP]:
can_lossless_cast(2 ** 54) === false
That one is incorrect, 2**54 *can* be exactly represented as a `float`.
The magic 2**53 boundary just means that the difference between
consecutive representable values becomes larger than `1`.
See:
> That suggests maybe the name should communicate "safe for JavaScript"; or
> more generally "safe for 64-bit IEEE floating point".
>
> is_safe_for_js()
> is_safe_for_float()
I'm not sure we should mention Javascript, because it's actually
related to floating point storage.
> I'm not sure if acc
On 26/07/2025 07:13, Alexandre Daubois wrote:
The idea is to have a function that receives an integer or a float and
returns bool if the provided argument is inside the safe Javascript
integer interval, namely [-(2^53)+1 ; (2^53)-1].
That suggests maybe the name should communicate "safe for Ja
Hello Rowan,
Le ven. 25 juil. 2025 à 23:10, Rowan Tommins [IMSoP]
a écrit :
> 1) You need to flesh out your proposal to be explicit about *what* it would
> do, as well as why.
Indeed, I was too focused on the why and I forgot the most important part.
The idea is to have a function that receive
On 25 July 2025 14:40:47 BST, Alexandre Daubois
wrote:
>
>I would like to gather feedback on the proposal to add an
>"is_integer_safe()" function to PHP.
From the name, I don't understand what this function would do. Do I pass in an
integer, and get a boolean telling me if it's safe? Safe for w
Hi Dmitry,
> On Jul 24, 2025, at 12:41, Dmitry Derepko wrote:
>
> Good catch for multi-classes per file with such feature, but I think it's not
> the time to do it.
...
> I think we should discuss the idea of the Short Constructor here. At least it
> does not require autoloading changes
Not
Good catch for multi-classes per file with such feature, but I think it's
not the time to do it.
As an alternative way to find the class is to look at the all files in the
namespace:
src/App/Controller/
IndexController.php
BlogController.php
IndexController.php contains
```
namespace
2025年7月15日(火) 16:05 youkidearitai :
>
> 2025年7月14日(月) 19:22 Derick Rethans :
> >
> > On Wed, 9 Jul 2025, youkidearitai wrote:
> >
> > > Hi, Internals
> > >
> > > I changed below the RFC.
> > > - https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive
> > > Pull request is below:
> > > - h
Hi all,
> On Jul 16, 2025, at 11:40, Deleu wrote:
...
> The blessing and the curse of PSR-4 is that it spoiled us (or maybe just me?)
> to:
>
> - never think about `require/include`
> - never think about composer.json
> - never think about how classes/interfaces/traits are located
> - IDEs wi
On Wed, Jul 16, 2025, at 17:44, Deleu wrote:
>
>
> On Wed, Jul 16, 2025 at 3:49 AM Rob Landers wrote:
>> __
>>
>> Why I haven't proposed it as a separate RFC: with PSR-4 being so popular,
>> nobody is going to write one-line files to take advantage of this. Thus,
>> when I was going to revisi
On Wed, Jul 16, 2025 at 12:59 PM Larry Garfield
wrote:
>
> I will reiterate what I have said many times in the context of function
> autoloading:
>
> The only autoloader that really matters in practice is Composer.
>
> Composer supports "front-load this list of files". You can put whatever
> you
On Wed, Jul 16, 2025, at 10:44 AM, Deleu wrote:
> On Wed, Jul 16, 2025 at 3:49 AM Rob Landers wrote:
>> __
>>
>> Why I haven't proposed it as a separate RFC: with PSR-4 being so popular,
>> nobody is going to write one-line files to take advantage of this. Thus,
>> when I was going to revisit n
On Wed, Jul 16, 2025 at 3:49 AM Rob Landers wrote:
>
> Why I haven't proposed it as a separate RFC: with PSR-4 being so popular,
> nobody is going to write one-line files to take advantage of this. Thus,
> when I was going to revisit nested classes later this year (after all the
> release shenani
On 7/16/25 13:56, Ayesh Karunaratne wrote:
Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls
be useful?
At this time there's no way to influence bcmath's behavior other than
bcscale().
How about adding these as methods/properties to the `BcMath\Number` class?
`BcMath\Nu
> Would adding a bcgetopts(): int and a bcsetopts(int $opts): void calls
> be useful?
>
> At this time there's no way to influence bcmath's behavior other than
> bcscale().
>
How about adding these as methods/properties to the `BcMath\Number` class?
`BcMath\Number` does not use the `bcmath.scale`
On Tue, Jul 15, 2025, at 20:07, Dmitry Derepko wrote:
> Hi,
>
> I've found a discussion about Records https://externals.io/message/125975 and
> found a one key point which I really like in Kotlin (hello): short
> constructors.
>
> Rob said that short constructor will be probably removed:
>> 1.
On Tue, Jul 15, 2025, at 1:07 PM, Dmitry Derepko wrote:
> Hi,
>
> I've found a discussion about Records
> https://externals.io/message/125975 and found a one key point which I
> really like in Kotlin (hello): short constructors.
>
> Rob said that short constructor will be probably removed:
>> 1.
2025年7月14日(月) 19:22 Derick Rethans :
>
> On Wed, 9 Jul 2025, youkidearitai wrote:
>
> > Hi, Internals
> >
> > I changed below the RFC.
> > - https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive
> > Pull request is below:
> > - https://github.com/php/php-src/pull/18792
> >
> > Change po
On Wed, 9 Jul 2025, youkidearitai wrote:
> Hi, Internals
>
> I changed below the RFC.
> - https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive
> Pull request is below:
> - https://github.com/php/php-src/pull/18792
>
> Change point is below:
> - Add a strength for grapheme_* function
On Mon, Jul 7, 2025, at 11:54, Claude Pache wrote:
> Hi,
>
> There is already a built-in function for that very purpose, namely
> `settype()`, see:
>
> https://www.php.net/settype
>
>
> —Claude
Thanks, Claude. Over twenty years of PHP development and I didn't know that
function exists (or I
> Le 7 juil. 2025 à 18:22, Joseph Leedy a écrit :
>
> Hello, I'm Joseph, or Seph for short. I'm a long time listener, but a
> first-time caller. I've had an idea rattling around in my noggin for a while
> that I'd like your feedback on:
>
> As a developer, I would like to have variables of o
On Mon, Jul 7, 2025, at 10:46, Rob Landers wrote:
> This is basically how non-strict mode works; there's no need for a cast. (I
> very rarely
> use strict mode, so I was a little confused on why you'd ever want to do this)
I always code in strict mode, so I find myself having to cast variables qu
On Mon, Jul 7, 2025, at 10:47, Alexandru Pătrănescu wrote:
>
> You need to use a slightly different syntax, maybe `(float)&$price;` that is
> an error now.
Apologies; I missed the ampersand in my example solution.
On Mon, Jul 7, 2025 at 7:25 PM Joseph Leedy
wrote:
>
> As a developer, I would like to have variables of one type cast to another
> type automatically so that I do not need to assign the variable to itself.
>
>
> What if we could do this instead?
>
> ```php
> $price = '5.0123';
> ...
> (float) $p
On Mon, Jul 7, 2025, at 18:41, Rob Landers wrote:
>
>
> On Mon, Jul 7, 2025, at 18:22, Joseph Leedy wrote:
>> Hello, I'm Joseph, or Seph for short. I'm a long time listener, but a
>> first-time caller. I've had an idea rattling around in my noggin for a while
>> that I'd like your feedback on
On Mon, Jul 7, 2025, at 18:22, Joseph Leedy wrote:
> Hello, I'm Joseph, or Seph for short. I'm a long time listener, but a
> first-time caller. I've had an idea rattling around in my noggin for a while
> that I'd like your feedback on:
>
> As a developer, I would like to have variables of one
> Le 6 juil. 2025 à 13:25, Tim Düsterhus a écrit :
>
> Hi
>
> On 7/5/25 13:52, Dmitry Derepko wrote:
>> I want to allow the "Partitioned" key to be set. Shall I open RFC or is it
>> possible to create only PR with improvements?
>> Also, I think it may be backported to all the actual PHP versio
Hi
On 7/5/25 13:52, Dmitry Derepko wrote:
I want to allow the "Partitioned" key to be set. Shall I open RFC or is it
possible to create only PR with improvements?
Also, I think it may be backported to all the actual PHP versions.
Just a PR should be fine, this follows an external standard and
On 5 July 2025 23:26:18 BST, Ben Ramsey wrote:
>The Partitioned parameter isn’t supported in Firefox or Safari. From what I
>can tell, it’s only supported in Chromium-based browsers. Safari 18.4
>supported it, but they removed the support in 18.5. I’d like to understand
>why, but I haven’t been
> On Jul 5, 2025, at 06:52, Dmitry Derepko wrote:
>
> Hi, Internals!
>
> A few days ago I faced some Cookie limitations, solutions led me to the CHIPS
> specification.
>
> Link:
> https://developer.mozilla.org/en-US/docs/Web/Privacy/Guides/Privacy_sandbox/Partitioned_cookies
>
> The idea of
Hi, Internals
I created an RFC and Draft PR.
- https://wiki.php.net/rfc/grapheme_add_locale_for_case_insensitive
- https://github.com/php/php-src/pull/18792
I would like to discussion.
Feel free to comment.
Regards
Yuya
--
---
Yuya Hamada (tekimen)
- https://tekitoh-mem
> Note that this RFC was about making the functions independent from the global
> mode as set by `setlocale()`.
>
> There is no issue in adding an explicit $locale parameter to those functions
> if the default value doesn’t depend on a global state.
>
> —Claude
>
Hi, Claude
Thanks for the commen
>
> However, I watched that RFC: https://wiki.php.net/rfc/strtolower-ascii
> and https://github.com/php/php-src/pull/7511,
> Perhaps, I should not locale-dependant for grapheme functions.
Note that this RFC was about making the functions independent from the global
mode as set by `setlocale()`.
2025年6月5日(木) 18:02 Claude Pache :
>
>
>
> > Le 5 juin 2025 à 03:04, youkidearitai a écrit :
> >
> > Hi, Internals
> >
> > I would like adds locale parameter that already there are grapheme_*
> > functions.
> > Because Unicode is locale-dependency but grapheme_* functions is not
> > locale-depende
> Le 5 juin 2025 à 03:04, youkidearitai a écrit :
>
> Hi, Internals
>
> I would like adds locale parameter that already there are grapheme_*
> functions.
> Because Unicode is locale-dependency but grapheme_* functions is not
> locale-dependency.
>
> For example, Add $locale parameter is bel
On Thu, 20 Feb 2025, 13:15 Mihail Liahimov, <91lia...@gmail.com> wrote:
> Now we have nullcoalesca operator in PHP:
>
> $a = $a ?? $b;
>
> And nullcoalesce assignment operator:
>
> $a ??= $b;
>
> (which is equivalent of previous example with nullcoalesce operator).
>
> Also we have a short syntax
On Sun, Dec 22, 2024 at 4:55 PM Calvin Buckley wrote:
> On Dec 22, 2024, at 10:57 AM, Kévin Dunglas wrote:
> >
> > On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote:
> > Thinking about it, there might be a possibility to address it (at least
> on Linux) using fanotify. Not sure about other p
On 22 December 2024 20:32:47 GMT, Niels Dossche wrote:
>All in all though, I'm not convinced by the parameter approach.
>I'd like a proper solution rather than some plaster.
>There are some options:
>1) Try to fix the stat cache.
>2) Put stat cache behind an ini knob.
>3) Get rid of the stat ca
On 22/12/2024 13:16, Rowan Tommins [IMSoP] wrote:
> On 21/12/2024 20:50, Niels Dossche wrote:
>> Adding a parameter for a cache, which should've been transparent in the
>> first place, to every file operation is messy.
>
>
> I would say it's less messy than having to work out when to turn a glob
On Dec 22, 2024, at 10:57 AM, Kévin Dunglas wrote:
>
> On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote:
> Thinking about it, there might be a possibility to address it (at least on
> Linux) using fanotify. Not sure about other platforms but maybe there are
> some solutions to address it.
On Sun, Dec 22, 2024 at 10:44 AM Jakub Zelenka wrote:
> Thinking about it, there might be a possibility to address it (at least on
> Linux) using fanotify. Not sure about other platforms but maybe there are
> some solutions to address it. Also it might get a bit complex and not sure
> how much th
On 21/12/2024 20:50, Niels Dossche wrote:
Adding a parameter for a cache, which should've been transparent in the first
place, to every file operation is messy.
I would say it's less messy than having to work out when to turn a
global setting on or off. In particular, it would be horrible fo
> I suppose a possible alternative would be to modify all file system
>> mutation functions (file_put_contents(), touch(), etc.) to flush the cache,
>> which for whatever reason doesn't happen now. That would be above my skill
>> level, though, so someone else would need to do it. Also, I don't k
On Sun, Dec 22, 2024 at 5:12 AM Larry Garfield
wrote:
> On Sat, Dec 21, 2024, at 10:43 AM, Jakub Zelenka wrote:
> > On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield
> wrote:
> >> Background: PHP has a not-often-considered feature, the stat-cache.
> That is, the runtime caches the OS stat() call fo
On Sat, Dec 21, 2024, at 10:43 AM, Jakub Zelenka wrote:
> On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield wrote:
>> Background: PHP has a not-often-considered feature, the stat-cache. That
>> is, the runtime caches the OS stat() call for files, so that subsequent
>> reads on the same file can be
On Sat, Dec 21, 2024, at 2:18 PM, Juris Evertovskis wrote:
> While it is nice the Symfony and WordPress wouldn't suffer a lot from
> dropping this cache, what's the impact on scripts that are processing
> hundreds of files?
>
> Would doing ` $stat = stat($filename);` instead of separate calls to
>
On 21/12/2024 21:38, Rowan Tommins [IMSoP] wrote:
>
>
> On 21 December 2024 18:49:46 GMT, Niels Dossche
> wrote:
>>> $perms = fileperms($name, statcache: true);
>>> $size = filesize($name, statcache: true);
>>
>> In my opinion, this will become very messy.
>
> Could you elaborate?
Adding a pa
On 21 December 2024 18:49:46 GMT, Niels Dossche wrote:
>> $perms = fileperms($name, statcache: true);
>> $size = filesize($name, statcache: true);
>
>In my opinion, this will become very messy.
Could you elaborate?
>Changing a default would be another BC break.
"Another" after what? Adding
While it is nice the Symfony and WordPress wouldn't suffer a lot from
dropping this cache, what's the impact on scripts that are processing
hundreds of files?
Would doing ` $stat = stat($filename);` instead of separate calls to
`filemtime` and `filesize` actually be important? Or would it still am
On 21/12/2024 19:43, Rowan Tommins [IMSoP] wrote:
> Rather than a global setting, which would make behaviour even more
> unpredictable in libraries and out-the-box applications, I wonder if we could
> make the cache explicit on the functions that use it?
>
> I'm thinking for instance of an extra
On 21 December 2024 16:43:39 GMT, Jakub Zelenka wrote:
>I would prefer to disable it by default but keep some option (INI) to
>re-enable it.
Rather than a global setting, which would make behaviour even more
unpredictable in libraries and out-the-box applications, I wonder if we could
make t
On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield
wrote:
> Background: PHP has a not-often-considered feature, the stat-cache. That
> is, the runtime caches the OS stat() call for files, so that subsequent
> reads on the same file can be faster. However, it's even less realized
> that it's a singl
On 20 December 2024 19:26:41 GMT, Larry Garfield wrote:
>There's been some discussion about making the cache disable-able, though the
>consensus now seems to be leaning toward getting rid of it outright:
>
>https://github.com/php/php-src/pull/17178
Just to fill in more context, which wasn't o
On 21.12.2024 at 06:49, Larry Garfield wrote:
> On Fri, Dec 20, 2024, at 3:35 PM, Christoph M. Becker wrote:
>
>> I still think the stat cache should be *deprecated* first. That gives
>> users a chance to reconsider calling multiple stat related functions
>> instead of doing a single stat() call.
On Fri, Dec 20, 2024, at 3:35 PM, Christoph M. Becker wrote:
> On 20.12.2024 at 20:26, Larry Garfield wrote:
>
>> Background: PHP has a not-often-considered feature, the stat-cache. That
>> is, the runtime caches the OS stat() call for files, so that subsequent
>> reads on the same file can be f
Am 20.12.2024 um 20:26 schrieb Larry Garfield:
Would you support such a removal?
+1 from me.
Here is an example of how the stat-cache can lead to interesting
situations in testing:
https://github.com/sebastianbergmann/phpunit/issues/5996#issuecomment-2422018481
On Fri, Dec 20, 2024 at 8:29 PM Larry Garfield
wrote:
> Background: PHP has a not-often-considered feature, the stat-cache. That
> is, the runtime caches the OS stat() call for files, so that subsequent
> reads on the same file can be faster. However, it's even less realized
> that it's a singl
Hi,
On Fri, Dec 20, 2024 at 10:37 PM Christoph M. Becker
wrote:
> On 20.12.2024 at 20:26, Larry Garfield wrote:
>
> > Background: PHP has a not-often-considered feature, the stat-cache.
> That is, the runtime caches the OS stat() call for files, so that
> subsequent reads on the same file can be
On 20.12.2024 at 20:26, Larry Garfield wrote:
> Background: PHP has a not-often-considered feature, the stat-cache. That is,
> the runtime caches the OS stat() call for files, so that subsequent reads on
> the same file can be faster. However, it's even less realized that it's a
> single-file
On Dec 20, 2024, at 3:26 PM, Larry Garfield wrote:
>
> Background: PHP has a not-often-considered feature, the stat-cache. That is,
> the runtime caches the OS stat() call for files, so that subsequent reads on
> the same file can be faster. However, it's even less realized that it's a
> sin
On Thursday, 21 November 2024 at 10:05, Christian Schneider
wrote:
> Am 14.11.2024 um 22:27 schrieb Gina P. Banyard intern...@gpb.moe:
>
> > Agreed, this bites us constantly when needing to reason about what an
> > "object" is in PHP.
> > Similar to array it mixes the concept of a struct, with
Am 14.11.2024 um 22:27 schrieb Gina P. Banyard :
> Agreed, this bites us constantly when needing to reason about what an
> "object" is in PHP.
> Similar to array it mixes the concept of a struct, with that of a reference
> value, and "overloading" various behaviours (e.g. iterators and ArrayAcces
I absolutely agree that unpacking objects to functions is a bad idea,
my use case for this is different.
Take for example that you have API endpoint that returns user balance
```php
readonly class Balance
{
public function __construct(
public float $debt,
public float $credit,
I do know about get_object_vars, but for me foreach ($object as $prop)
{} looks nicer and a little bit faster (probably because there are no
function calls). Also it's more flexible because in future you can
implement an Iterator on class and alter iteration behavior.
But after reading through http
On Thursday, 14 November 2024 at 17:24, Larry Garfield
wrote:
> On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote:
>
> > Am 14.11.2024 um 10:59 schrieb Marco Pivetta ocram...@gmail.com:
> >
> > > On Thu, 14 Nov 2024, 11:29 MrMeshok, ilyaorlov...@gmail.com wrote:
> > >
> > > > Hello,
On Thu, Nov 14, 2024, at 7:37 AM, Christian Schneider wrote:
> Am 14.11.2024 um 10:59 schrieb Marco Pivetta :
>> On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote:
>>> Hello, Internals!
>>>
>>> As you know if you try to unpack a regular object (`...$object`) you will
>>> get an error: Only arrays and T
Am 14.11.2024 um 10:59 schrieb Marco Pivetta :
> On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote:
>> Hello, Internals!
>>
>> As you know if you try to unpack a regular object (`...$object`) you will
>> get an error: Only arrays and Traversables can be unpacked.
>> I don't really see a reason for this
On Thu, 14 Nov 2024, 11:29 MrMeshok, wrote:
> Hello, Internals!
>
> As you know if you try to unpack a regular object (`...$object`) you will
> get an error: Only arrays and Traversables can be unpacked.
> I don't really see a reason for this restriction, because foreach on
> objects works perfec
2024年10月6日(日) 14:45 youkidearitai :
>
> 2024年10月5日(土) 1:20 Tim Düsterhus :
> >
> > Hi
> >
> > Am 2024-09-25 09:21, schrieb youkidearitai:
> > > I tried implement mb_levenshtein function and create an RFC.
> > > https://wiki.php.net/rfc/mb_levenshtein
> > > https://github.com/php/php-src/pull/16043
On Fri, Oct 11, 2024, at 12:48 PM, Oladoyinbo Vincent wrote:
> Hello everyone, earlier this morning, I visited the official Python website
> and discovered a section highlighting what Python is used for. This section
> provides a brief overview of the most popular frameworks and libraries built
2024年10月5日(土) 1:20 Tim Düsterhus :
>
> Hi
>
> Am 2024-09-25 09:21, schrieb youkidearitai:
> > I tried implement mb_levenshtein function and create an RFC.
> > https://wiki.php.net/rfc/mb_levenshtein
> > https://github.com/php/php-src/pull/16043
> >
> > I would like discussion, feel free to comment.
Hi
Am 2024-09-25 09:21, schrieb youkidearitai:
I tried implement mb_levenshtein function and create an RFC.
https://wiki.php.net/rfc/mb_levenshtein
https://github.com/php/php-src/pull/16043
I would like discussion, feel free to comment.
Thank you for your RFC. I share the concern raised by cm
Hi Folks
Thanks for the replies. If interface default methods are not entirely off
the table, then I agree that's a far better option, for sure! I'll hold off
on writing my arguments for them until a thread pops up, I think it makes a
lot of sense though.
So consider the idea of traits + interfac
On Tuesday, 27 August 2024 at 09:25, Brent Roose
wrote:
> Back to PHP, using traits as types seems impossible, since traits are a
> compile-time copy/paste mechanism, which means there’s no type information
> available about them at runtime.
>
> However, allowing traits to implement interfaces
> On Aug 30, 2024, at 10:15 AM, Larry Garfield wrote:
> I would be very much in favor of revisiting Interface Default Methods,
> though, as I think it would be a strong feature, and it's one found in nearly
> all of our sibling languages at this point. PHP is weird for not having
> them. I be
1 - 100 of 559 matches
Mail list logo
