On Mon, Jun 16, 2025, at 09:05, wheakerd wrote:
> Dear PHP Internals,
>
> I am submitting this proposal for discussion regarding a potential future
> direction for PHP: moving toward a CLI-only development model and introducing
> an optional Ahead-of-Time (AOT) compilation infrastructure.
>
>
Hi!
> I’m sorry; you’ve lost me here.
>
> How does "short-lived" execution fail in serverless or event-driven
> environments? Isn’t that the entire point? Serverless is basically a
> reinvention of CGI, which PHP excels at. However, the people who built
> these runtimes didn’t realise what they w
On Mon, Jun 16, 2025, at 2:05 AM, wheakerd wrote:
> Dear PHP Internals,
>
> I am submitting this proposal for discussion regarding a potential
> future direction for PHP: moving toward a CLI-only development model
> and introducing an optional Ahead-of-Time (AOT) compilation
> infrastructure.
>
On Mon, Jun 16, 2025, at 20:10, Larry Garfield wrote:
> On Mon, Jun 16, 2025, at 10:18 AM, Olle Härstedt wrote:
> > Hello Internals,
> >
> > I was pondering a little about effect handlers today, and how they could
> > work as a replacement for dependency injection and mocking. Let me show an
> >
Den mån 16 juni 2025 kl 20:11 skrev Larry Garfield :
> On Mon, Jun 16, 2025, at 10:18 AM, Olle Härstedt wrote:
> > Hello Internals,
> >
> > I was pondering a little about effect handlers today, and how they could
> > work as a replacement for dependency injection and mocking. Let me show
> an
> >
On Mon, Jun 16, 2025, at 10:18 AM, Olle Härstedt wrote:
> Hello Internals,
>
> I was pondering a little about effect handlers today, and how they could
> work as a replacement for dependency injection and mocking. Let me show an
> example:
>
>
> require_once("vendor/autoload.php");
>
> use Latitud
On Sun, Jun 15, 2025, at 9:04 AM, Daniel Kesselberg wrote:
> Hi Larry,
>
> Thanks for your feedback.
>
> I've reworked the introduction at
> https://wiki.php.net/rfc/num_available_processors and hopefully the use
> case is a bit clearer now.
>
> Best
> Daniel
It is, thanks.
For the name, I do
On 16.06.25 17:21, Rob Landers wrote:
On Mon, Jun 16, 2025, at 16:54, Alexandru Pătrănescu wrote:
On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz wrote:
Hi all,
It's 12.5 years only until the timestamps in PHP on 32bit will
not work
as expected anymore.
Hi,
I think that
Hi all,
On 16 Jun 2025, at 17:24, Rob Landers wrote:
>
>
>
> On Mon, Jun 16, 2025, at 16:54, Alexandru Pătrănescu wrote:
>>
>>
>>
>> On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz wrote:
>> Hi all,
>>
>> It's 12.5 years only until the timestamps in PHP on 32bit will not work
>> as expe
Hi,
Great tip, thank you, I had forgot about those! Will try.
Olle
Den mån 16 juni 2025 kl 17:32 skrev Rob Landers :
>
>
> On Mon, Jun 16, 2025, at 17:18, Olle Härstedt wrote:
>
> Hello Internals,
>
> I was pondering a little about effect handlers today, and how they could
> work as a replaceme
On Mon, Jun 16, 2025, at 17:18, Olle Härstedt wrote:
> Hello Internals,
>
> I was pondering a little about effect handlers today, and how they could
> work as a replacement for dependency injection and mocking. Let me show an
> example:
>
>
> require_once("vendor/autoload.php");
>
> use Lati
Hello Internals,
I was pondering a little about effect handlers today, and how they could
work as a replacement for dependency injection and mocking. Let me show an
example:
query = $query;
}
}
class Plugin
{
/* The "normal" way to do testing, by injecting the db object. Not
needed here.
On Mon, Jun 16, 2025, at 16:54, Alexandru Pătrănescu wrote:
>
> On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz wrote:
>> Hi all,
>>
>> It's 12.5 years only until the timestamps in PHP on 32bit will not work
>> as expected anymore.
>>
>
> Hi,
>
> I think that maybe we can already deprecate
On Mon, Jun 16, 2025 at 4:03 PM Marc Bennewitz wrote:
> Hi all,
>
> It's 12.5 years only until the timestamps in PHP on 32bit will not work
> as expected anymore.
>
>
>
Hi,
I think that maybe we can already deprecate supporting 32 bit builds.
And, maybe with PHP 9, or PHP 10, or with a future ve
If you use 32bit version of PHP then of course you will run into this
problem. But 32bit versions are used infrequently now, and this is a
known limitation. As far as I know, these functions have no issues
with year 2038 in 64bit. My point is that these functions work fine
and the fact that 32bit i
Hi Calvin,
On 16/06/2025 16:21, Calvin Buckley wrote:
On Jun 16, 2025, at 10:28 AM, Matteo Beccati wrote:
Hi,
as mentioned in https://github.com/php/php-src/pull/15949 I still think that
PARAM_LOB can safely be used as identifier for binary data, as pdo_mysql and
pdo_pgsql do.
I think P
On 16.06.25 16:16, Kamil Tekiela wrote:
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLh
I wouldn't be opposed to deprecating them, but I don't know if we have
a good enough reason to do so.
https://3v4l.org seems to be 64bit now ;) -> https://3v4l.org/1F
Including the EOL versions on that link shows that this occurs on <
5.2.6 only
On 16/06/2025 16:16, Kamil Tekiela wrote:
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLh
I wouldn't be opposed to deprecating them, but I don't know if we have
a good enough r
On Jun 16, 2025, at 10:28 AM, Matteo Beccati wrote:
>
> Hi,
>
> as mentioned in https://github.com/php/php-src/pull/15949 I still think that
> PARAM_LOB can safely be used as identifier for binary data, as pdo_mysql and
> pdo_pgsql do.
>
I think PARAM_LOB and PARAM_BINARY are orthogonal.
Us
Why do you say that these functions do not work with year 2038?
https://3v4l.org/61VLh
I wouldn't be opposed to deprecating them, but I don't know if we have
a good enough reason to do so.
On Mon, Jun 16, 2025 at 03:01:00PM +0200, Marc Bennewitz wrote:
> Alternatively, zend_long could be migrated to int64_t or arbitrary integers
> like proposed by Andrea Faulds back in 2014
>
> What do you think?
>
https://wiki.php.net/rfc/bigint
+1
--
Alain Williams
Linux/GNU Consultant - Mail
Hi,
as mentioned in https://github.com/php/php-src/pull/15949 I still think
that PARAM_LOB can safely be used as identifier for binary data, as
pdo_mysql and pdo_pgsql do.
Cheers
On 15/06/2025 16:52, Gina P. Banyard wrote:
On Wednesday, 23 October 2024 at 17:36, Calvin Buckley
wrote:
H
Hi
Am 2025-06-16 09:05, schrieb wheakerd:
To make PHP compilable in AOT mode, certain dynamic features must be
restricted or restructured. The following are required:
[…]
b. **Unified Standard Library**
- Procedural global functions (e.g., `strlen`, `array_merge`) are
consolidated into ba
Hi
Am 2025-06-15 19:30, schrieb Daniel Kesselberg:
How do we continue? ;) I see there are various ideas how to approach
it, is that something you would vote (let's do a or b) on, or how does
that work?
Having secondary votes is generally frowned upon for this kind of simple
RFCs. It's mostly
Hi all,
It's 12.5 years only until the timestamps in PHP on 32bit will not work
as expected anymore.
The DateTime[Immutable] classes use 64bit integers internally already
but there are still a couple of places where this is an issue in the API
due to PHP integer limit:
Based on that I pers
Dear PHP Internals,
I am submitting this proposal for discussion regarding a potential future
direction for PHP: moving toward a CLI-only development model and
introducing an optional Ahead-of-Time (AOT) compilation infrastructure.
While this may not fully align with PHP’s traditional interpreter
26 matches
Mail list logo
