Re: [PHP-DEV] Zephir, and other tangents

[Pierre Joye]

On Sat, Sep 21, 2024, 3:41 AM Dennis Snell 
wrote:

>
> On Sep 20, 2024, at 1:21 PM, Jakub Zelenka  wrote:
>
> Hi,
>
> On Fri, Sep 20, 2024 at 6:32 PM Dennis Snell 
> wrote:
>
>>
>> My goal in sharing here is to help better represent my own perspective of
>> WordPress’ needs based on what I’ve seen. It’s long been on my list to
>> propose a WASM RFC, but because I personally haven’t had the priority
>> available to get an implementation working I haven’t done so. It’s my
>> impression from the documentation that the purpose of these email threads
>> w.r.t. RFCs is to gather interest and input before any RFC would be put
>> together, to hold these discussions before anyone commits any major time to
>> it.
>>
>
> Is your objective to support building PHP to wasm32-wasi target like it
> was proposed here: https://github.com/php/php-src/pull/10457? If so, the
> main issue with that was inability to do the zend_bailout as wasm does not
> support currently support setjmp and longjmp. Otherwise it's mostly about
> disabling some functionality.
>
>
> It’s the other way around. We’ve been having a great time already building
> PHP as a WASM binary - we package it with SQLite and WordPress to create
> “The WordPress Playground.” There’s a wonderful new world of things that
> can happen when packaging PHP inside a WASM runtime.
>
> However, this is about calling compiled WebAssembly code from user-space
> PHP.
>
> load_wasm( __DIR__ . ‘/interesting-computation.wasm’ );
> $description = null;
> call_wasm_func( ‘lazy_json_decode’, $json, ‘items[0].description’,
> $description );
>

this is a very important target which is not directly discussed in this
thread.

I played with the (very good) IR when it was submitted by Dmitry back then.
It sounded like the most effective way.

However it was not designed (nothing  bad with that) with such goals in
mind. I was hoping it could be used like any other IR (similar to what llvm
does f.e.) to then target wasm. The closest one from php is python with
py2wasm, but there are pretty existing solutions that make it possible,
they use the out of python core approach:

https://wasmer.io/posts/py2wasm-a-python-to-wasm-compiler

which looks very much like what could be done with php as I see the chances
to have that in php as very low without major changes.

best,
Pierre

It may be possible but the time required to figure it out is not something
I have sadly (falling back to porting our php code to other when we need it
to be used in many environments where putting a php is not an option).

As of now, I feel like writing a parser-compiler may be easier, even with
limited features. But ideally the way could be to allow it the same way we
can see it in other languages, but the paradigms used are very different.

All in all, it is not absolutely vital for php to have this but it will
help to keep it on for the next 2 decades. Similarly to other discussions
lately about new types.

best,
Pierre

>

Re: [PHP-DEV] Which IDE do you recommend for php-src development?

[Pierre]

Le 14/09/2024 à 23:44, Barel a écrit :

Hi

For C/C++ development I usually use CLion from Jetbrains but I tried 
to use it with php-src and was unable to get it to work properly. 
CLion really insists on using CMake and has only quite limited support 
for makefiles. After trying to get it to work unsuccessfully I am 
ready to try something else.


So which IDE would you recommend for php-src development? I understand 
that people probably have many different preferences but I wondered if 
there was something that most php internals developers used. One 
important feature would be to easily work with the project running on 
a docker container


Thanks in advance!

Carlos


Eclipse for C/C++ developers may work as well. I did use it for writing 
an xdebug patch and reading the PHP source code.


Regards,

Pierre

Re: [PHP-DEV] Re: [INTERNALS-WIN] ext/gd: drop XPM support on Windows

[Pierre Joye]

On Thu, Sep 12, 2024, 4:42 PM Christoph M. Becker  wrote:

> On 12.09.2024 at 06:46, Pierre Joye wrote:
>
> > I mentioned that long ago, but a maybe faster way to get windows ready
> > sources is vcpkg:
> >
> > https://vcpkg.roundtrip.dev/ports/libxpm
> >
> > only changes required are for static lib names, as we use _a to
> > differentiate. lib for dll or static links.
>
> Dropping our own builds in favor of some package manager is a worthwhile
> goal, but might be much harder than it seems.
>

sorry, I was not asking to use vcpkg, it has been discussed before as you
remind us in this reply :)

But the src are windows build ready and many of our less maintained deps
are maintained there.

best,

>

[PHP-DEV] Re: [INTERNALS-WIN] ext/gd: drop XPM support on Windows

[Pierre Joye]

hi,

On Thu, Sep 12, 2024, 5:04 AM Christoph M. Becker  wrote:

>
>
> This should be fixed in winlibs/libxpm.  The patch in winlib-builder
> doesn't make sense; I think I did this to make it easier to update
> libxpm, though in hindsight this was probably a bad idea.
>

I mentioned that long ago, but a maybe faster way to get windows ready
sources is vcpkg:

https://vcpkg.roundtrip.dev/ports/libxpm

only changes required are for static lib names, as we use _a to
differentiate. lib for dll or static links.

best.

>

[PHP-DEV] Re: [INTERNALS-WIN] ext/gd: drop XPM support on Windows

[Pierre Joye]

hi Christoph,

On Wed, Sep 11, 2024, 7:56 PM Christoph M. Becker  wrote:

> Hi all,
>
>
> Therefore I suggest dropping XPM support from ext/gd on Windows as soon
> as possible (might be a bit late for PHP 8.4, but might still be a good
> idea).
>

Given it is only useful on OSes relying on X/freedesktop, the impact should
be zero.

best,

[PHP-DEV] Re: [INTERNALS-WIN] Maintain Windows PHP dependency builds in a GH repo

[Pierre Joye]

Hi Christoph,

On Sun, Sep 8, 2024 at 4:32 PM Christoph M. Becker  wrote:

> * the process is prone to error

Originally, it was thought to do first this (painful) manual process
to validate the flow. Then the plan was to use the releases in each
dep's repository. Having one repository to define which version-build
is needed per php version (incl patch version, f.e. security update).
That has never been done.

It was also a step required for out of php-src extension builds
(pickle partially has it, no idea where the new tool stands about
this). But that's a bit off topic here :)

> What do you think?

100% for it.

> Would this require the RFC process?

A documentation for sure, especially for external developers
(nativephp, roadrunner, etc) so they can use it for their own flows.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

[Pierre Joye]

On Thu, Aug 15, 2024, 6:35 AM Lanre  wrote:

> Arvids wrote "I don't think C sees a lot of development any more, so it
>> makes sense to move towards C++."
>
>
>
>>
> Nah, I meant the specific conversation with Pierre Joye, it wasn't going
> anywhere. I stand by all my points so why would I just leave because of
> some confused folks?
>

it ends on the clarification about being related to ease extension support
for c++.

I also have to reitere my earlier suggestion. Please stop telling others
here they have no clue, are clueless, ignorant or what else.

it is ok to disagree, even strongly. This tone however is not ok, at all.

thanks for your understanding.

Pierre

>

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

[Pierre Joye]

On Wed, Aug 14, 2024, 11:07 AM Lanre  wrote:

>
> On Tue, Aug 13, 2024 at 4:28 PM Mike Schinkel  wrote:
>
>>
>> On Aug 12, 2024 at 4:13 PM, > wrote:
>> You’d have to be seriously naive to believe that “the entire industry is
>> actively trying to move AWAY from C/C++.”
>>
>>
>> Well, there is this:
>>
>>
>> https://media.defense.gov/2023/Dec/06/2003352724/-1/-1/0/THE-CASE-FOR-MEMORY-SAFE-ROADMAPS-TLP-CLEAR.PDF
>>
>> -Mike
>>
>
> The source mentions Python and Swift as "memory-safe languages," both of
> which are implemented in C and C++. How does that work if C and C++ aren't
> memory-safe?
>

This is the wrong analyze and approach. How many issues happen the past
years in the core of a language vs the apps using it would be a better data.

As another example, go is written in go btw.

My argument about using other languages to write extensions or sapi for php
is about ease the development and allow more people to do it. FrankenPHP is
a very good example. There are others.

Mozilla introduced Rust years ago, yet Firefox remains primarily C++, with
> only about 3% of the codebase in Rust. By dismissing C and C++, one
> overlooks the fact that they are crucial for powering everyday systems such
> as elevators, automotive control units (ECUs, ADAS), medical devices,
> consumer electronics, industrial automation, and more.
>
Some of my code running automates on z80 still run. Yet, newer models use
mips cpu and C.

Similarly cobol is still used, so are some c cgi applications.



It IS naive to believe that “the entire industry is actively trying to move
> AWAY from C/C++.”.
>

you are extrapolating for the sake of it. Every industry has a certain
latency to move from one tech to another (or non tech).

It does not prevent new solutions to grow and be used.

also the main topic being how to handle the few cases using c++
dependencies have been elegantly solved already.

>

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

[Pierre Joye]

On Tue, Aug 13, 2024, 3:16 AM Lanre  wrote:

I'm sure the idea of enhancing C++ makes no sense to you, and would be a
> waste of your time and energy, but not everyone is that stupid/incompetent
> so even if i do get bored of maintaining it, literally any C++ dev can pick
> it up, it really is that simple.
>

Your previous reply related to the misunderstanding about your proposal
(engine vs extension support) was enough.

Now,  this reply and the previous one go way beyond an acceptable,
respectful discussion.  Please stop it and reconsider the way your
communicate your disagreements or arguments.

>

Re: [PHP-DEV] [DISCUSSION] C++ Enhancements in Zend API

[Pierre Joye]

On Mon, Aug 12, 2024, 11:03 PM John Coggeshall  wrote:

>
> > I’m considering adding some C++ enhancements to the Zend API.
>
>
> I would definitely like to see an RFC for this if it was to be considered.
> To me, adding a whole new way of doing things internally without completely
> removing the old way is just asking for a more brittle, potentially less
> secure, and harder to maintain codebase. The win of making it easier /
> "nicer" on a subset of developers who might prefer a C++ interface isn't
> anywhere near worth the risk IMO.
>


if anything, I would rather go with rust (zig would have my preference ;-).
The benefits would be to have a significant ease to contribute for many.

Neither of c++ or rust would be easy to add. The later would have the huge
advantage to bring a little bit more safety to the extensions APIs.

A less diplomatic answer would be that c++ makes zero sense in 2024 for php
(or any other language), a strong and bold take :)

best,
Pierre

Re: [PHP-DEV] PDO_Firebird: use C++?

[Pierre Joye]

On Sun, Aug 11, 2024, 8:32 PM Gina P. Banyard  wrote:

> On Sunday, 11 August 2024 at 15:26, Pierre Joye 
> wrote:
>
>
>
> On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard  wrote:
>
>> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
>> cmbecke...@gmx.de> wrote:
>>
>> I think moving the PDO driver to use C++ is a more sensible choice.
>>
>
>
> what would be the advantages? given the OO part at the C level is
> perfectly fine in C and the actual OO parts are really zend classes and co?
>
>
> I didn't say to rewrite the whole extension.
> Considering the library we are going to be depending on is in C++ it makes
> more sense to do what the ext/intl extension does, which is to use C++.
> I do not want the project to have to deal with a broken C transpilation
> error created by an external tool (namely CLOOP).
>
> If you have a better suggestion on how to deal with this issue, feel free
> to do so.
>

ah you mean only for fb? makes sense yes. While I prefer to add a thin
layer to expose it as c and keep the engine&co use in c, a tat bit easier
with little impact  :)

Re: [PHP-DEV] PDO_Firebird: use C++?

[Pierre Joye]

On Sun, Aug 11, 2024, 6:53 PM Gina P. Banyard  wrote:

> On Saturday, 10 August 2024 at 15:13, Christoph M. Becker <
> cmbecke...@gmx.de> wrote:
>
> I think moving the PDO driver to use C++ is a more sensible choice.
>


what would be the advantages? given the OO part at the C level is perfectly
fine in C and the actual OO parts are really zend classes and co?

Re: [PHP-DEV] [Discussion] Sandbox API

[Pierre Joye]

On Wed, Aug 7, 2024, 7:13 PM Nick Lockheart  wrote:

>
>
>
> So I was thinking about this a bit more and I thought, what if instead
> of adding a sandbox as a feature of PHP, what if PHP *was* the sandbox.
>
> So consider this:
>
> What if the PHP engine added a C API that lets C/C++ programs not only
> spin up and run PHP, but those C/C++ programs could also control and
> monitor the execution of the PHP environment from the outside.
>


Something similar is done in things like frankenphp (go/caddi/own sapi) or
nativephp (desktop app, afair rust/tauri).

Not the same goal, same starting point.

But I would stay away to replace, or improve, OS security with my own
things. Totally possible but it is the kind of worms can I don't look
forward to open  :)

>

Re: [PHP-DEV] [Discussion] Sandbox API

[Pierre Joye]

On Wed, Aug 7, 2024, 2:11 AM Rob Landers  wrote:

>
> I find this assertion kind of scary from a shared hosting perspective or
> even from a 3v4l kind of perspective. How do these services protect
> themselves if php is inherently insecure?
>

php is not inherently insecure. not even remotely and quite the opposite.

Shared hosting is.

This is issue is not specific to php, almost all languages out there will
have the same memory (or else) challenges.

Crypto apis or similar features requiring high level of safety for the data
use various technics to mitigate it (zeroing after use, decrypt mem on
demand only etc).

A bit off topic but with the solutions out there for vps, etc, shared
hosting for anything requiring data safety should be avoided like the pest.


About this feature, it looks, at a first glance,  like an advanced complex
version of safe mode/open base dir, with the additional features. I never
ever had to mock core functions for testing, I would think about a design
issue if it is needed.


But I may be wrong, that would not be a first  :)


cheers,
Pierre

Re: [PHP-DEV] Require C11 in PHP 8.4

[Pierre Joye]

On Tue, Aug 6, 2024 at 12:10 AM Christoph M. Becker  wrote:
>
> On 05.08.2024 at 17:42, Pierre Joye wrote:
>
> > On Mon, Aug 5, 2024, 10:03 PM Derick Rethans  wrote:
> >
> >> Instead of having to deal with tickets, wouldn't be be easier if the
> >> compiler they used works with the features that we are using? That could
> >> instantly provide a link to the documentation saving all of us time.
> >
> > it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11
> > compliant (not 4.7).
>
> But what about other compilers we support on non Windows platforms
> currently, like clang, Apple's clang, Solaris Studio and maybe some more
> we don't even know about.

Sorry, I meant to actually check if that feature is supported with
AC_COMPILE_*. It is painful but has proven to be the only reliable
way.

As gcc or VCC can be slightly more trusted using their versions, the
other, especially on MacOs, can't be trusted, ever. Let alone on other
OSes I still wonder why we support them for latest php 8 versions
(solaris f.e.).

> > As of windows, it will be dependent on the vc version used by the php minor
> > branch where it may be introduced.
>
> It's supposed to be introduced as of PHP 8.4.0, which already uses VS
> 17, although MSVC supports C11 as of VS 16.5 (while it never claimed to
> support C99).  So in practise, even those still building their own
> Windows binaries with Visual Studio 2019 should not be affected.
>
> > That being said, I am not sure if the reason mentioned for using c11 in the
> > initial post is used in external extensions (included headers etc), but at
> > least on linux (or similar), an ext can be compiled with any version.
>
> I somewhat doubt that; we're using a couple of C99 features (like mixed
> declarations and statements) in the core for a couple of years (IIRC, as
> of PHP 8.0.0), and extensions may do this with their own code, or might
> be forced to include public php-src headers which may use some C99
> features.  This may not be an issue with any C compilers actually still
> in use, but can be sure about that?

We can't :).

To my understanding the challenges are the extensions maintainers. On
Windows it is a controlled environment. We had similar discussions
back then when we dropped VC6, which was a much bigger step. I would
prefer to go with what makes your work easier than trying to keep
older VC support for the latest release, in case we decide to support
a minimum VC version for valid reasons. atomic support seems to be
one, the header one, I am very doubtful about it as something worth
the troubles :). This is being only about windows, that's indeed not
valid for any linux/*bsd/*wrt/etc.

cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

Re: [PHP-DEV] Require C11 in PHP 8.4

[Pierre Joye]

On Mon, Aug 5, 2024, 10:03 PM Derick Rethans  wrote:

> Instead of having to deal with tickets, wouldn't be be easier if the
> compiler they used works with the features that we are using? That could
> instantly provide a link to the documentation saving all of us time.
>


it is significantly easier at configure time. Gcc 4.9 is (almost) fully c11
compliant (not 4.7).

As of windows, it will be dependent on the vc version used by the php minor
branch where it may be introduced.

That being said, I am not sure if the reason mentioned for using c11 in the
initial post is used in external extensions (included headers etc), but at
least on linux (or similar), an ext can be compiled with any version.

On windows, we can't, mainly for memory  management issues (alloc/realloc
or freed using different crt). It is possible but too many extensions, also
in core, cause issues.

best,
Pierre

>

Re: [PHP-DEV] tsrm question

[Pierre Joye]

On Wed, Jul 24, 2024 at 7:06 PM Rob Landers  wrote:
>
> On Wed, Jul 24, 2024, at 13:54, Pierre Joye wrote:
>
> Hi Rob,
>
>
> On Wed, Jul 24, 2024 at 3:17 PM Rob Landers  wrote:
> >
> > Hello internals,
> >
> > Last night I went down a rabbit hole with Frankenphp: 
> > https://github.com/dunglas/frankenphp/pull/933
> >
> > It isn't 100% clear to me what values `ts_resource(id)` holds and if it 
> > needs to be freed/allocated per request or per thread. The performance 
> > impact is huge to reallocate on every request (mostly due to the global 
> > mutex during allocation). Is anyone familiar with this and could help 
> > reviewing the changes there?
>
> I suppose you already looked, but if not, maybe it gives you some 
> direction(s).
>
> The key part is kind of documented here:
>
> https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/TSRM/TSRM.c#L417
>
> tsrm knows nothing about requests but only threads.Its jobs are about
> threads data.
>
> A good start (surely already looked) are apache and litespeed (or
> embed) for php8, however besides the API names change, the behavior or
> goals of each ts_ or tsrm_ functions remain the same as what we had
> with 5.x. One with a very similar modus operandi than Franken was
> ISAPI for IIS. Mind the names changes, dapt to php8's new names (and
> some behaviors) but the basics and core flows have been kept.
>
> If you know (~) how many threads franken is going to need, tsrm allows
> you to preallocate the rsc slots using tsrm_startup_ex. It uses
> tsrm_startup, a more powerful version, which lets franken define how
> many rsc per thread will be preallocated. I suppose that could help a
> bit performance wise:
>
> https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/main/main.c#L2716C13-L2716C25
>
> As per the last question, about when to free them:
> tsrm_shutdown (franken shutdown) will free all rsc
>
> When a thread is detached (franken kills it for example),
> ts_free_thread needs to be called to kill its rsc. They will be freed
> anyway too but good to be clean.
>
> The tsrm resource management will also automatically purge orphan rsrc
> (f.e. when a thread dies unexpectedly and ts_free_thread could not be
> called).
>
> Long story short, the TSRM API is very flexible, how and when you
> alloc/free rsrc is basically up to you. It is possible to keep some
> around in the root thread (and be used in other threads, given the
> root thread id is known (can be 0 or else depending how franken
> managed them.
>
> I hope it helps and did not say too many outdated/wrong explanations :).
>
> Btw, Welting rewrote that part with Dmitry back then to fix long
> standing issues (and drop TSRM_LS/DC/CC uses), not sure if he is still
> around but he may help.
>
> Best,
> --
> Pierre
>
> @pierrejoye | http://www.libgd.org
>
>
> Hey Pierre,
>
> Thank you! This helps tremendously.
>
> A good start (surely already looked) are apache and litespeed (or
> embed) for php8, however besides the API names change, the behavior or
> goals of each ts_ or tsrm_ functions remain the same as what we had
> with 5.x. One with a very similar modus operandi than Franken was
> ISAPI for IIS. Mind the names changes, dapt to php8's new names (and
> some behaviors) but the basics and core flows have been kept.
>
>
> I looked at litespeed but not apache, so I will look to that as well.

Sorry, I forgot to copy that link, php5 but core flow is the same:

https://github.com/php/php-src/blob/bcd100d812b525c982cf75d6c6dabe839f61634a/sapi/isapi/php5isapi.c#L938

--
Pierre

@pierrejoye | http://www.libgd.org

Re: [PHP-DEV] tsrm question

[Pierre Joye]

On Wed, Jul 24, 2024, 7:06 PM Rob Landers  wrote:

>
> The number of threads are static (at least for now), so we should def do
> this.
>
> Long story short, the TSRM API is very flexible, how and when you
> alloc/free rsrc is basically up to you. It is possible to keep some
> around in the root thread (and be used in other threads, given the
> root thread id is known (can be 0 or else depending how franken
> managed them.
>
>
> Ah, so this is where I was getting confused. It's unclear what the "id" is
> and what it is used for. For example, I see the engine has a couple of ids
> (compiler/execution) but I'm unclear what the sapi should be doing with
> them. Should these "ids" be different per thread, or is it just an
> arbitrary key?
>

there are two ids you can pass. The rsc ID and the thread ID.

By default the thread ID will be the current thread.

the rsrc is the one you get when creating a new rsc (fetching a non
existent one will create it btw).

I would suggest to read the comments in the implement of ts_resource, lot
of useful information are explained there :)

best,
Pierre

Re: [PHP-DEV] tsrm question

[Pierre Joye]

Hi Rob,


On Wed, Jul 24, 2024 at 3:17 PM Rob Landers  wrote:
>
> Hello internals,
>
> Last night I went down a rabbit hole with Frankenphp: 
> https://github.com/dunglas/frankenphp/pull/933
>
> It isn't 100% clear to me what values `ts_resource(id)` holds and if it needs 
> to be freed/allocated per request or per thread. The performance impact is 
> huge to reallocate on every request (mostly due to the global mutex during 
> allocation). Is anyone familiar with this and could help reviewing the 
> changes there?

I suppose you already looked, but if not, maybe it gives you some direction(s).

The key part is kind of documented here:

https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/TSRM/TSRM.c#L417

tsrm knows nothing about requests but only threads.Its jobs are about
threads data.

A good start (surely already looked) are apache and litespeed (or
embed) for php8, however besides the API names change, the behavior or
goals of each ts_ or tsrm_ functions remain the same as what we had
with 5.x. One with a very similar modus operandi than Franken was
ISAPI for IIS. Mind the names changes, dapt to php8's new names (and
some behaviors) but the basics and core flows have been kept.

If you know (~) how many threads franken is going to need, tsrm allows
you to preallocate the rsc slots using tsrm_startup_ex. It uses
tsrm_startup, a more powerful version, which lets franken define how
many rsc per thread will be preallocated. I suppose that could help a
bit performance wise:

https://github.com/php/php-src/blob/8e93eb2e79cea5fcca6769b46a429de042660da9/main/main.c#L2716C13-L2716C25

As per the last question, about when to free them:
tsrm_shutdown (franken shutdown) will free all rsc

When a thread is detached (franken kills it for example),
ts_free_thread needs to be called to kill its rsc. They will be freed
anyway too but good to be clean.

The tsrm resource management will also automatically purge orphan rsrc
(f.e. when a thread dies unexpectedly and ts_free_thread could not be
called).

Long story short, the TSRM API is very flexible, how and when you
alloc/free rsrc is basically up to you. It is possible to keep some
around in the root thread (and be used in other threads, given the
root thread id is known (can be 0 or else depending how franken
managed them.

I hope it helps and did not say too many outdated/wrong explanations :).

Btw, Welting rewrote that part with Dmitry back then to fix long
standing issues (and drop TSRM_LS/DC/CC uses), not sure if he is still
around but he may help.

Best,
--
Pierre

@pierrejoye | http://www.libgd.org

Re: [PHP-DEV] ext/gd new imagematch function (was: adding imagecompare)

[Pierre Joye]

hi,

as I mentioned in the PR, this is an old function which we did not touch
for bc reasons.

I also linked a better image comparison function used for the gd tests
suite. It covers exaxf match which is what it seems you are aiming to get.

Additionally that function also return an image with the difference (the
diff images contains the channels differences).

A key, more tricky, but nevertheless important compared is a perceptual
difference, but that can be done additionally.

best,
Pierre

On Thu, Jul 11, 2024, 4:39 PM Giovanni Giacobbi 
wrote:

> The recent PR #14877 [1] proposes to add the imagecompare gd function that
> mimics the gdImageCompare function from libgd. I always thought that a
> pixel-by-pixel matching function for two images was a big missing feature
> in PHP, as the corresponding userland implementation is really, REALLY slow.
>
> The problem with gdImageCompare is that it checks several aspects of the
> two images, and fails on its core purpose. The behavior is better seen in
> its source code [2] rather than explained. I see the following problems:
> - The gdImageCompare is kind of buggy, as it completely disregards the
> alpha channel. As a user, I would expect that two images that have a pixel
> rgba(255, 0, 0, 100%) and one rgba(255, 0, 0, 50%) are considered
> different, but the current implementation reports them as identical.
> - Checking for bitmasks is cumbersome, and it requires 9 new constants in
> the global namespace (the IMG_CMP_*), which are nearly useless. Most use
> cases will just want to check for this: imagecompare($im1, $im2) &
> IMG_CMP_IMAGE.
> - The checks in gdImageCompare are also a bit arbitrary, why compare the
> interlace flag but not the palette order? Why check the number of colors in
> the palette if they are not even used in the image?
> - If a user is interested in the other checks, they can all be implemented
> in userland with existing functions: imageinterlace, imagecolortransparent,
> imageistruecolor, imagesx, imagesy, imagecolorstotal.
>
> I believe PHP should only offer required building blocks and leave to the
> libraries the implementation of more structured functionality. My proposal
> is a completely different function called imagematch() that solves the
> exact problem of the pixel-by-pixel matching, with the added value of
> optionally matching portions of the images, using the following signature:
>
> function imagematch(GdImage $image1, GdImage $image2, int $x1 = 0, int $y1
> = 0, int $x2 = 0, int $y2 = 0, ?int $width = null, ?int $height = null):
> bool {}
>
> I already drafted PR #14914 [3] with the first two parameters. There is
> not an equivalent libgd implementation, so the implementation is entirely
> on the php side, but as you can see it's quite trivial. Even with the
> extended functionality of matching portions of the images it would be just
> a few extra lines of code, so not a big maintenance burden.
>
> If an RFC is required, I'm happy to redact it after the initial feedback
> round.
>
> [1] https://github.com/php/php-src/pull/14877
> [2]
> https://github.com/php/php-src/blob/5586d0c7de00acbfb217e1c6321da918b96ef960/ext/gd/libgd/gd.c#L2834
> [3] https://github.com/php/php-src/pull/14914
>
>

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Pierre]

Le 21/06/2024 à 15:57, Robert Landers a écrit :

On Fri, Jun 21, 2024 at 3:01 PM Pierre  wrote:

Le 21/06/2024 à 14:27, Robert Landers a écrit :

This is why I wanted to work on "as" part of the pattern matching. It
isn't clear what will happen with the actual pattern matching RFC
(yet), but being able to do:

  some_function_expecting_int($_GET['foo'] as ?int);

And how about:

some_function_expecting_int(\intval($_GET['foo']));

And moreover, I'd write something like this, but:

function validate_int(mixed $value): int {
 if (null === $value || '' === $value) {
 return null;
 }
 if (\is_int($value)) {
 return $value;
 }
 if (\is_string($value) && \ctype_digit($value)) {
 return \intval($value);
 }
 throw new \InvalidArgumentException("What what!");
}

some_function_expecting_int(validate_int($_GET['foo'] ?? null));

But the example might be erroneous, I see your point, nevertheless making 
coercion explicit doesn't seem really relevant to me, the one point I like in 
your syntax would be null handling.

--

Pierre

Or... you could just turn off strict types instead of reinventing
coercion that isn't nearly as well documented as the built-in
coercion.


That was one of my points actually.

I don't see the use of a syntax such as `$foo as ?int` since all 
existing types of coercion are already possible via the cast syntax 
(please correct me if I'm wrong).


In the previous message proposal, the only neat addition was the null 
handling (that's said, that's a really cool point). But cast syntax 
`(int) $foo` is really equivalent to `$foo as int` in terme of concision 
(less than 2 chars diff).


In almost every case you would need coercion you also need validation, 
and validation is not something that's possible with a neat syntax, at 
least not this one, because validation is a business matter, not really 
a technical one.


Regards,

--

Pierre

Re: [PHP-DEV] Renaming "strict types" to "scalar type coercion"

[Pierre]

Le 21/06/2024 à 14:27, Robert Landers a écrit :

This is why I wanted to work on "as" part of the pattern matching. It
isn't clear what will happen with the actual pattern matching RFC
(yet), but being able to do:

  some_function_expecting_int($_GET['foo'] as ?int);


And how about:

some_function_expecting_int(\intval($_GET['foo']));

And moreover, I'd write something like this, but:

function validate_int(mixed $value): int {
if (null === $value || '' === $value) {
return null;
}
if (\is_int($value)) {
return $value;
}
if (\is_string($value) && \ctype_digit($value)) {
return \intval($value);
}
throw new \InvalidArgumentException("What what!");
}

some_function_expecting_int(validate_int($_GET['foo'] ?? null));

But the example might be erroneous, I see your point, nevertheless 
making coercion explicit doesn't seem really relevant to me, the one 
point I like in your syntax would be null handling.


--

Pierre

Re: [PHP-DEV] Bumping minimum PostgreSQL version to 10.0

[Pierre]

Le 14/06/2024 à 22:54, Peter Kokot a écrit :

Hello,

we're thinking of bumping the minimum PostgreSQL version supported by PHP from
current version 9.1 to version 10.0:
https://github.com/php/php-src/pull/14540

A list of PostgreSQL versions and their EOL dates can be seen at
https://en.wikipedia.org/wiki/PostgreSQL

The versions coverage by Linux/Unix distributions can be found at
https://pkgs.org

For example:
- https://pkgs.org/search/?q=libpq
and
- https://pkgs.org/search/?q=postgresql

This is aligning with CentOS 7 EOL in June 2024 and CentOS 8. PostgreSQL 10 is
already EOL but to provide easier migration for packages, I think such
increase is ok.

Anyone have any concerns or thoughts about this?


Would id affect the possibility to use an old PostgreSQL (eg. 9.6) via 
PHP (PDO or ext-pgsql) ?


If so, it might be a dangerous move for oldest projects, you sometime 
can upgrade PHP and your software easily, but can't upgrade the database 
server.


Regards,

Pierre

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

[Pierre]

Le 07/06/2024 à 21:38, Larry Garfield a écrit :

On Fri, Jun 7, 2024, at 7:20 PM, Pierre wrote:


I sincerely do not want to see a new operator for replacing the "new"
operator, because then we would have two different syntaxes which would
be semantically equivalent.

Creating a new object, in most API design, is not something you do very
often, especially when working in a framework that does it for you
(dependency injection, etc...).

This is not entirely true.  Creating a new service object, yes, you rarely 
never do that yourself.  Creating a new data object (value object, struct 
object, DTO, and a dozen other terms) is something that should happen more than 
most PHP developers currently do, because most of us have primitive obsession.  
(Or array obsession.)

Consider attributes: Any time you want to have an object as the value for one of the arguments to 
an attribute, you need a "new."  Any time you create a value object for a more strongly 
typed parameter than the horrid $options array, you'll be using "new."

So I'm sympathetic to making that syntax easier, and would be OK with it if a 
workable syntax was found.  But so far in this thread, a workable syntax has 
not been found.

I agree it's not the greatest usability concern in PHP right now, though.

--Larry Garfield


I understand your point, but why replacing "new" which is basically an 
operator, with another operator ?


I do agree with you that when you use value objects, you need it a lot, 
but I'd much prefer having a JS like value objects initializer syntax, 
such as `Point {x: 1, y: 2}` syntax than creating another way to call 
the constructor, which already has a mastered and comprehensive syntax 
which is simply `new`.


As you said, it's not the greatest usability concern in PHP right now.

Pierre

Re: [PHP-DEV] RFC proposal : "new" keyword shorthand

[Pierre]

Le 07/06/2024 à 18:03, Benoît Condaminet a écrit :

Hello,

Following the RFC process, I'm sending this to propose a PHP change. 
More precisely a new zend language token.


This is somehow linked to the recently accepted RFC called "new 
MyClass()->method() without parentheses", the goal is to introduce a 
shorthand for the "new" keyword.


*Motivations :*
The new keyword sometime has a bad DX, for example when chaining Class 
instantiation like this :

$foobar = new Foo( new Bar(), new Etc());

We can quickly have very long class object construction in some case.

In lot of Framework, to improve DX, static function construct are 
often used to avoid the new keyword, some create additional object 
builders, etc.


As a first try, I start updated code to completely make the new 
keyword optional, like in Dart language for example, but it require 
very big change, with lot of impact (collision with function).


So here is *my proposal : *

Add a "new" shorthand, using the tilde character : "~"
I made a POC, and it works well, declaring a new language 
token T_SHORT_NEW that simply reuse ZEND_AST_NEW under the hood.



Hello,

I sincerely do not want to see a new operator for replacing the "new" 
operator, because then we would have two different syntaxes which would 
be semantically equivalent.


Creating a new object, in most API design, is not something you do very 
often, especially when working in a framework that does it for you 
(dependency injection, etc...).


And, moreover, when I'm searching who what where was created an specific 
class instance, I regex grep for "new\s+ClassName" and in most case, it 
works like a charm. If you add an operator for this, it simply will 
create a huge cognitive dissonance for simply no added value at all.


"New" is working fine, adding a shortcut for the sake of adding a 
shortcut to something you don't write that much doesn't worth it in my 
opinion: there are much more disadvantages that benefits.


Best regards,

Pierre

Re: [PHP-DEV] [RFC] [Vote] #[\Deprecated] attribute

[Pierre]

Le 22/05/2024 à 09:33, Nicolas Grekas a écrit :

Hi Benjamin,

The vote for the RFC #[\Deprecated] attribute is now open:

https://wiki.php.net/rfc/deprecated_attribute

Voting will close on Wednesday 5th June, 08:00 GMT.


I voted "no" because I think this is better addressed in userland, as 
this gives more flexibility.
I would better have an attribute that is made only for static analysis 
with no runtime side effects at all.
Being forced to make the attribute final because the implementation in 
the engine requires is an example of why the engine is not the correct 
place to send this notice. Another example is not being able to add 
the attribute on classes because [engine reasons].


trigger_error() is better fitted for the runtime side-effect when it's 
desired.
In my opinion, #[Deprecated] should be only for static analysers / 
reflection (although this would need another discussion - I'm not sure 
this would benefit being in the engine vs in a userland package.


Thanks for the RFC anyway.

Nicolas


I'm always dubious when I read the "this can be addressed or better 
addressed in userland": as soon as you need something as little as the 
Deprecated attribute, if it's not in core but in userland, you encounter 
two very serious issues: first one, fragmentation, every framework, 
organisation, or static analysis tool will have its own variant, second 
one if the community converges toward a single one, you then will be 
dependent on a certain framework or huge tooling.


I can see many benefits in having this in core, one being that every 
static analyzer will implement it using the core attribute, so any 
project and developer using it can choose any static analysis tooling 
without having to change or adapt its code everywhere, or learning a 
different convention in order to use different tools.


That's my 2 cents, but the "better in userland" argument seems to me 
almost always biased or wrong. Especially for this Deprecated argument, 
this a very common need, and each project Doctrine, Symfony, any tool 
implement it in a different manner. I don't want to be rude, but as a 
developer using all of those, it's very annoying having to learn 
different ways of doing something as simple and naive that saying that a 
function is deprecated. One manner is sufficient, even if not perfect.


--

Pierre

Re: [PHP-DEV] RFC idea: using the void type to control maximum arity of user-defined functions

[Pierre]

Le 04/04/2024 à 23:38, Mark Trapp a écrit :

On Thu, Apr 4, 2024 at 2:16 PM Bilge  wrote:

On 04/04/2024 16:57, Tim Düsterhus wrote:

I think it would be reasonable to consider deprecating passing extra
arguments to a non-variadic function.

This seems like the only reasonable thing to do, to me. If this were the
case, there should be no need for any new syntax, since we could simply
deny passing extra arguments in the next major, no?

Bilge

I'd caution about being too hasty to deprecate and remove support for
this feature without understanding the underlying reasons why it has
been used historically, and without providing a better (not just
different) alternative for those use cases, lest an impossible upgrade
path is created.

While the variadic operator should be a 1:1 replacement for using
func_get_args(), is it enough of a benefit to force potentially tens
of thousands of codebases to change when they both accomplish the same
thing? What bad thing happens if PHP continues to support both
methods?

There is already enough friction to upgrade between major versions.
Introducing an optional attribute or syntax allows codebases that care
about signature strictness get that safety, while avoiding a
potentially costly and onerous upgrade for the community.

- Mark


I agree with both, ie. I think it's reasonable to deprecate extra 
variadic arguments, but also do it with caution: some old code, some 
templating systems for example may use implicit variadic arguments to 
pass values to templates.


There are tons of use case like this in old yet still running code.

But I would love it to be deprecated, raise warnings, and give some time 
for people to fix (adding an explicit `mixed ... $values` is enough to 
fix broken code).


Cheers,

--

Pierre

Re: [PHP-DEV] [RFC[ Property accessor hooks, take 2

[Pierre]

Le 21/02/2024 à 19:55, Larry Garfield a écrit :

Hello again, fine Internalians.

After much on-again/off-again work, Ilija and I are back with a more polished 
property access hooks/interface properties RFC.  It’s 99% unchanged from last 
summer; the PR is now essentially complete and more robust, and we were able to 
squish the last remaining edge cases.

Baring any major changes, we plan to bring this to a vote in mid-March.

https://wiki.php.net/rfc/property-hooks

It’s long, but that’s because we’re handling every edge case we could think of. 
 Properties involve dealing with both references and inheritance, both of which 
have complex implications.  We believe we’ve identified the most logical 
handling for all cases, though.

Note the FAQ question at the end, which explains some design choices.

There’s one outstanding question, which is slightly painful to ask: Originally, 
this RFC was called “property accessors,” which is the terminology used by most 
languages.  During early development, when we had 4 accessors like Swift, we 
changed the name to “hooks” to better indicate that one was “hooking into” the 
property lifecycle.  However, later refinement brought it back down to 2 
operations, get and set.  That makes the “hooks” name less applicable, and 
inconsistent with what other languages call it.

However, changing it back at this point would be a non-small amount of grunt 
work. There would be no functional changes from doing so, but it’s lots of 
renaming things both in the PR and the RFC. We are willing to do so if the 
consensus is that it would be beneficial, but want to ask before putting in the 
effort.


Yes please ! Pass !

I don't have voting rights, but we need this.

Cheers,

Pierre R.

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

On Mon, Jan 1, 2024, 6:18 PM Rowan Tommins  wrote:

> On 31 December 2023 16:31:31 GMT, Pierre Joye 
> wrote:
>
> >php handles this in threadsafe mode
>
> Depending on your exact definition of "php", this is either irrelevant or
> just plain wrong.
>
> If you mean "the HTTP SAPIs shipped with official builds of PHP", then
> it's true, none handle multiple concurrent requests in a single thread
> using async I/O. But none handle multiple consecutive requests in a single
> thread using a "worker mode" either, which is the whole point of this
> conversation.
>


Unless I misunderstand the current proposal, it is about providing a core
interface to allow one to create its own SAPI similar to FrankenPHP, which
does not handle request in a singe thread but a thread pool handled by go's
coroutine.

I can imagine other developers implement it using other mechanisms (rust or
c++ f.e.) but the main interface from a php internal pov remains.

It is a first step and based on the usages/feedback, the next steps could
be the second part of your comment. Or?

best,
Pierre

>

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

hello,

On Sun, Dec 31, 2023, 6:59 PM Rowan Tommins  wrote:

Then one of us is missing something very fundamental. As I understand it,
> Swoole's model is similar to that popularised by node.js: a single thread
> processes multiple incoming requests concurrently, using asynchronous I/O.


The nodejs curse yes, where async and co may actually slow down your whole
node.

 DB result
> 09 Request A formats and returns response
> 10 Request A complete
> 11 Request B resumed
> 12 Request B fornats and returns response
>

php handles this in threadsafe mode, like modphp f.e. It is why frankenphp
requires a TS build of php. Requests are handled by a thread pool, not in
single thread event loop which may block all requests.

best,
Pierre

Re: [PHP-DEV] RFC proposal: worker mode primitives for SAPIs

[Pierre Joye]

Hello,

On Tue, Dec 26, 2023, 1:56 AM Jordan LeDoux  wrote:

>
> So you want to introduce a SAPI that doesn't work with any of the existing
> HTTP solutions people use that only supports HTTP requests? Or am I
> misunderstanding something?
>
> This sounds a bit like you want to merge in a tool that is designed for
> your personal product directly into core. FrankenPHP may be incredible and
> awesome, but the world runs on Apache and Nginx for HTTP requests.



The world was running on cgi when php was created and a few years after.
Then the world was running on threads/apache. Then it ran in fcgi and
finally fcgi fpm for the last few years.

Other languages support this since quite some time. Projects like reactphp,
swoole and the likes provide userland versions of it and the benefits are
clear. They even worked together recently to get a common core. Many
(large) projects out there already support FrankenPHP, the needs are there.

FrankenPhp and a worker mode go beyond the classical php usages we had.
Desktop applications or IoT are getting more common (see laravel's
nativephp f.e.). I have done something similar for one of our products
using embedded sapi but how it is done using frankenphp would be an order
of magnitude better.

Having the complex parts in the core us a good start to experiment, adapt.
Later a core sapi may be added, we cannot know without trying and let the
community uses it.

best,
Pierre

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

On Mon, Dec 11, 2023, 11:21 PM Larry Garfield 
wrote:

> On Mon, Dec 11, 2023, at 9:46 AM, Derick Rethans wrote:
>
> > Yeah, I understand. And I feel the same. But if there is no registry (a
> > goal), then there is no way to find out which of your extension version
> > support a specific PHP version, without checking every tag in your
> > repository. That's not going to be fast.
> >
> > cheers,
> > Derick
>
> See, I think I disagree on this point.  Having a registry is table-stakes
> for package managers these days.  Composer, npm/yarn, whatever Python does
> this week, Cargo, Bundle, Maven/Gradle... a packager isn't complete without
> a registry.  The one exception is Go, and its approach is... just a mess,
> frankly.
>
> Whether PECLtng piggybacks on Packagist, self-hosts using something like
> Satis, or does a home-grown thing, I don't think a neo-PECL without a
> registry is a viable and sustainable way forward.  That needs to be in the
> initial design.
>

hi Larry,

you are fully right here.

On top of the already mentioned points, it brings visibility to extension
packages, which is a key factor to adoption at large.

It also helps for an automatic builds.

A service is also a must for automatic releases/triggers builds. You can
see this service with a github tag hook on pickleweb.

It is also quite a good thing to automate dependencies management. It could
be relatively straightforward to update them per distros, or windows (see
my earlier post, already managed using windows. php.net data).

Also without the services (implemented but no public packagist for
extensions yet), I think pickle already does 95% of it (including local
windows builds). Adding signature is relatively simple.

Important note, during pickle development, the number 1 request was to be
fully integrated with composer. it was not possible until composer v2,
plugin and custom tags.  Given that composer is the only used package
manager , it should be the way to go. To create something from scratch
without taking these points into accounts can only lead to a sub optimal
solution.

There are also development environments tools out there which could provide
relatively easily per project extensions management (either cli or pools).

PHP is not my primary platform anymore, business wise, however I am happy
to help if desired.  I can only, with a diplomatic emphasis, suggest to the
author to understand where the php ecosystem is (or was 3 years or more
ago).


best,
Pierre

>

Re: [PHP-DEV] Filesystem path APIs

[Pierre Joye]

On Fri, Dec 8, 2023, 3:44 PM Max Semenik  wrote:

> On Wed, Dec 6, 2023 at 10:20 PM Niels Dossche 
> wrote:
>
> > Hi internals
> >
> > I'd like to start a pre-RFC discussion about filesystem path APIs in PHP.
> > The reason I bring this up is because of this recent feature request:
> > https://github.com/php/php-src/issues/11258
> >
> > The feature request is about the following:
> > We already have some functions to work with paths in PHP, e.g. basename,
> > dirname, realpath.
> > We do not have some common path APIs that you can find in other languages
> > like: path_join to join paths and path_normalize to normalize paths.
> >
>
> We have a lot of commonly used functionality that's successfully fulfilled
> by Composer packages - does this really have to be core functionality?
>

if any of them could be a easy win, relative path resolver without checking
its existence would be one. It is available internally but the existence
check option is not exposed.

>

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

Hello Tim,

On Wed, Dec 6, 2023 at 9:05 AM Tim Starling  wrote:

> Have you considered keeping the support matrix in the registry
> database, instead of in pecl.json? Then it can be updated with new
> build/test information after release.

We do it for windows, used by pickle, you can see one part here:

https://windows.php.net/downloads/php-sdk/deps/dllmapping.json

The other parts being part of each extension.

It could be achieved similarly for linux package managers, maybe
maintained by them directly.

A few years back, I made some tests on windows and linux using
https://conan.io/ and https://vcpkg.io/, they both work on most
platforms PHP supports and also have cmake integration (php build
using cmake has been worked done, very nicely :).

Having maintained these parts for many years, dealt with 3rd parties
(developers of librairies, distro packages maintainers, etc) as well
as dealt with many end users (php developers), I must say I would
absolutely not start to define our own things but rely as much as
possible on the well working existing solutions.

On the same topic, npecl's requirements (why not a RFC/proposal btw?)
are kind of out of sync with what I have seen and still see. F.e.,
doing it outside the composer ecosystem will most likely create a
niche and not a wide adoption.There have been a lot of efforts put
into similar topics since 5.3 and a lot of learning, it may be a good
thing to learn from them. There are also tools now available to give
developers out of box tools to define whatever environments they may
need and switch between them within a click or command line (Laravel
community created a few good ones, mac for the biggest one, and other
platforms), having them rely on php's platform for the core and non
core extensions (including their respective deps) will be amazingly
helpful.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

On Tue, Dec 5, 2023, 10:13 PM Pierre Joye  wrote:

>
>
> You may mention https://github.com/FriendsOfPHP/pickle
>
> which supports pecl.php.net pear format,  composer like support, and
> conversion to composer format.
>
> I did a website as well as a test bed and we had a long with the composer
> team what would be the best way to integrate it. That's something that
> became possible with composer 2.x, which now widely used. Similarly we
> discussed the idea to create a packagist dedicated to extensions.
>
> That would be, imo, the best option to date.
>
>
> The current code may need some updates for php8 but nothing difficult or
> requiring big changes.
>

there was also a draft rfc while we were thinking to propose to bundle it.
But we then decided to follow the composer's packagist philosophy instead.

https://wiki.php.net/rfc/pickle

>

Re: [PHP-DEV] New "PECL"

[Pierre Joye]

Hi Derick,

On Tue, Dec 5, 2023, 8:45 PM Derick Rethans  wrote:

> Hi there!
>
> Within the PHP Foundation, we have been talking for a while as what to
> do with PECL, and its website.
>
> The code is old, and hard to maintain. And the database is full of
> mojibake. It is also an outdated method of installing things, especially
> because userland code is so much easier to handle through Composer.
>
> Through the Sovereign Tech Fund (https://www.sovereigntechfund.de/) the
> Foundation has acquired some funding to improve this situation.
>
> Hence, to start of replacing PECL with something applicable for this
> decade, we started working on a requirements document:
>
>
> https://docs.google.com/document/d/1_N0E9xo3jn9aKrIZHIbTYaY5lXw71BpSO6-it4cRpDo
>
> In this first stage, we would like to invite you in commenting on the
> document (either inline, or here).
>
> Please keep in mind that this is a requirements document, and should not
> contain either design or implementation details. Once we have thought
> about these details as well, this will be turned into an RFC.



You may mention https://github.com/FriendsOfPHP/pickle

which supports pecl.php.net pear format,  composer like support, and
conversion to composer format.

I did a website as well as a test bed and we had a long with the composer
team what would be the best way to integrate it. That's something that
became possible with composer 2.x, which now widely used. Similarly we
discussed the idea to create a packagist dedicated to extensions.

That would be, imo, the best option to date.


The current code may need some updates for php8 but nothing difficult or
requiring big changes.


best,
Pierre

Re: [PHP-DEV] Make PHP JIT to generate AVX2/AVX3 for performance improvement?

[Pierre Joye]

On Tue, Oct 31, 2023, 3:57 PM tag Knife  wrote:

> > Hi  Guys,
> >
> > A quick question: is it possible to enable AVX2/AVX3 in PHP JIT generated
> > code, and hence can get some performance improvement?
> > Just check the community first: if anyone has already tried that or got
> > some experiences? before we dive into this investigation.
> > We are discussing if we could get some extra performance via new AVX
> > instructions in PHP program execution.
> >
> > Thanks.
> >
>
> AVX3 might be too new to just flat out generate for it. But
> It can be quite simple for the JIT compiler to be aware of what
> features flags are enabled on a CPU and generate compatible
> instructions that will run on that CPU.
>

it is not really new, however the gain for most cases are not necessarily
significant but for specific cases.

For most usages in php, at a request level, the gain will be barely
measurable.

Also for latest avx, most hosting servers won't have them anyway.

I would think some specific APIs to prepare specific data to be processed
using the best available runtime intrinsics would bring much more than in
JIT.

As a sidenote, most libraries used by php,  where larger intrinsics vectors
bring something, implement them already.


best,
Pierre

>

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 18:11, Saki Takamachi a écrit :

If I understand your use case properly, you should be confused by properties 
with default values that are not constructor-promoted as well ? Am I wrong ? In 
this case, your problem is not with promoted properties ?

If we specify it the way you say, the initial values ​​of the constructor 
arguments will be available even when the constructor is not called.

Such behavior felt a little counterintuitive.


Which then would simply be the same behavior as properties when not 
promoted but declared in the class body instead:


```php

class Foo
{
    public $val = 'abc';
}

$redis_foo = serialize(new Foo());

$foo = unserialize($redis_foo);
var_dump($foo->val);
// string(3) "abc"

```

Right ?

What's the most disturbing in my opinion is that: `class Foo { public 
string $val = 'abc' }` and `class Foo { public function 
__construct(public string $val = 'abc' ) {}}` don't yield the same 
behavior at the time.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 17:35, Saki Takamachi a écrit :

Hi, Pierre

You may have overlooked the existence of the magic method `__unserialize()`. 
Constructor is not the only way to create instances.

When rebuilding a serialized object, you may need the initial values ​​of 
properties. This can easily happen if you are using rolling updates and using 
Redis. The constructor is not called if `__unserialize()` is called. In this 
case, defining the initial value of a property as an argument to a constructor 
that is never called confuses us.

Regards.

Saki


If I understand your use case properly, you should be confused by 
properties with default values that are not constructor-promoted as well 
? Am I wrong ? In this case, your problem is not with promoted properties ?


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Constructor promoted property and default value

[Pierre]

Le 23/10/2023 à 17:16, Larry Garfield a écrit :

Where this becomes a problem is readonly properties, since those are not 
allowed to have default values.  (That would make them constants with worse 
performance.)  A solution would need to be able to detect that the 
parent::__construct() isn't called, and then call it anyway, or at least 
partially call it.  Unfortunately, I can think of many cases where such a call 
would result in unexpected behavior.

It might be possible to resolve, but it's definitely not simple, and it could 
easily lead to weird behavior.

--Larry Garfield


Thanks for the explanation !

I see, there is no easy answer, yet current state is, in my opinion, 
unintuitive for developers, and eventually unsatisfying when falling in 
this trap.


That's sad that readonly properties make this not trivial. Maybe some 
kind of object construct-post-hook could detect those case and affect 
variables with default values ? I don't know enough PHP internals to 
give a rational answer to this problem through...


Regards,

--

Pierre

[PHP-DEV] Constructor promoted property and default value

[Pierre]

Hello internals,

I stumbled upon this behavior, if I write this:

```php
class Foo
{
    public ?string $prop = null;

    public function __construct(?string $prop = null)
    {
    $this->prop = $prop;
    }
}

class Bar extends Foo
{
    public function __construct(
    public ?string $bar = null,
    ) {}
}

// Echoes nothing, but it works as expected.
echo (new Bar())->prop;
```

It works as intended, but if I replace the `Foo` class using:

```php
class Foo
{
    public function __construct(
    public ?string $prop = null,
    ) {}
}
```

It won't work anymore and I have the following error:

```
PHP Warning:  Uncaught Error: Typed property Foo::$prop must not be 
accessed before initialization in php shell code:9

```

If I understand it correctly:
 - in the first case, default value is attached to the object property, 
so if I omit its constructor, I have the default,
 - in the second case, default value is attached to the constructor 
parameter, and not to the object property, which means that in case the 
parent constructor is not called in the `Bar` class, `$prop` remains 
initialized.


It doesn't sound like a bug, but I think that many people would actually 
expect otherwise: that the constructor promoted property keep their 
default even when constructor is not explicitly called.


Is there any good reason behind this ? Wouldn't it be best to change 
this behavior ? Would it be a risk for backward compatibility (my guess 
is "not that much, probably not a all even") ?


Regards,

--
Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Custom object equality

[Pierre]

Le 18/10/2023 à 22:22, Jordan LeDoux a écrit :


While I (obviously) appreciate the goal of the proposal here since I 
wrote the gigantic operator overload RFC the last time it was 
proposed, I do not support this idea here for one very simple reason: 
it is a clunky, work-around implementation to try and get the benefits 
of operator overloads without actually doing it.
Even if I don't really like operator overload, I would very much prefer 
the gigantic operator overload to pass than a band-aid patch with a new 
operator, I'm all in for consistency.


The need to control comparisons is real and obvious. So long as voters 
are categorically opposed to actual operator overloads no matter the 
implementation, as represented here by you Pierre but by no means a 
position that only you hold, I don't think we should be looking for 
ways to get the functionality through hacks like this. It may get 
passed in the short term and get PHP developers the equality 
comparison control that objects desperately need, but it makes all 
future improvements almost impossible to do.


Maybe I don't master english enough and I can speak to strictly 
sometime. If an operator overload RFC that doesn't have any blind spot 
or weird edge case happens, I'd be happy to see it pass, at least it 
would close bike shedding around this topic and life would continue happily.


I can't vote, but if I could, I wouldn't vote against a proper, robust, 
and easy to debug for developers operator overload RFC, I would simply 
abstain, because even if I personally don't like it, lots of people want 
it and I'm simply one among millions of PHP users, I don't want anyone 
to be frustrated.


The most important thing in my previous message I wanted to say was that 
the "~" symbol refers to something "approximate" in many contexts, in my 
opinion it's not the right choice for an equality operator. My opinion 
is either go for a full-on proper operator overload or simply don't.


Regards,

--

Pierre

Re: [PHP-DEV] Previous discussions about generics syntax only?

[Pierre]

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 
SomeDoctrineRepository so that my IDE would actually give me 
the right autocompletion.


There's also another use where it would get even better:

```

EntityManager::find(Query): T

class SomeQuery implements Query {}

// Later in code:

$someEntity = $entityManager->get(new SomeQuery())

assert($someEntity instanceof T); // Is now useless, my IDE simply knows.

```

There are many simple use case that can make our life easier, outside of 
simply array, lists, vectors etc...


Even if type erasure is done and there no runtime checks, it would 
greatly help when correctly done at the right place by userland APIs. 
ORM's are one place, but there are many others.


Regards,

--

Pierre

Re: [PHP-DEV] Custom object equality

[Pierre]

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 skip writing boilerplate equals() methods which just forward
equals() to the nested objects
- standardize such comparisons on the language level

Of course how exactly this operator looks may be changed, `~=` is just an
example.

WDYT?


I'm not fond of operator overloading, I actually quite hate it, I like 
the expressiveness of an equals() method.


I would very much prefer to have a set of standard interfaces such as 
Comparable { compareTo($other): int } or Equatable { equals($other): 
bool; } which the standard API and userland libraries could make use of.


In all cases, I don't like the ~= choice because in my mind it literally 
translates to "is approximately/barely/maybe comparable to".


By the way, please  do not use abbreviations such as WDYT, I'm not a 
native english speaker and I don't know all abbreviations, I had to 
duckduckgo' it.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Previous discussions about generics syntax only?

[Pierre]

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 doesn't address all of the concerns) is a good
idea right now.


Documentation is not code, and you could have syntax errors within 
without ever knowing it. Documentation is documentation and static 
analysis based upon documentation is fragile. All static analyzers may 
not even be in phase, when you contribute to projects you have to learn 
code style and conventions, but you also have to learn documenting style 
and conventions, and you must add the fact that from one project to 
another, generics documentation convention changes. Even thought you 
think it's "community decided convention", not all tools are in sync, 
sadly, and not all the community is OK with it.


I don't use PHPStorm, it's not the only IDE out there, or even people 
use simple editors sometime. Not all of them will have the same support 
level regarding "community decided convention". And even worse, most 
advanced IDE implementation may actually drive the "community decided 
convention" and steal the "democratic syntax vote" from the community, 
it's a very bad move where people that make money by selling their IDE 
may become the one driving the syntax and convention, and which will 
then en-prison their users in using their IDE, sometime the only 
supporting the convention they created themselves. OK, it's probably not 
that true, but at a very theoretical level, it's what it is.


When new syntax elements arise within a new PHP version, all editors, 
IDE, LSP backends will adopt it immediately, whereas it's definitely not 
true for "community decided convention". You have one, then two, then 
some static analysis tool or some IDE adds new subtle changes, new 
syntax, you never have, and will never have, at any point in time, a 
situation where all tools are in sync.


I do love the idea to have the syntax at PHP level with type erasure 
because it's not a "community decided convention" anymore, but a parser 
syntax that the engine supports which has been discussed and voted for, 
it is being validated, and exposed in reflection, which makes it 
resilient, solid, usable, and universal.


Having type erasure eliminates runtime checks, but it still can pose the 
basis for later real runtime checks. I like the idea even thought I'm 
not fully comfortable with regarding later feasibility, if the syntax is 
wrong and things cannot be implemented later in the engine, they the 
result would be catastrophic (everyone who have used it would have to 
fix all their code later when another solution would be chosen).


I'm aware this isn't an easy topic, and I have no solution for it. But 
"community decided convention" is not a solution either, it's at best, 
some kind of band-aid, and at worst, creating confusion because 
conventions differs from project to project, from tooling to tooling, 
and it's terrible for developers.


Regards,

--

Pierer

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Pierre]

Le 15/10/2023 à 18:09, Larry Garfield a écrit :

That has already been done:https://www.php.net/array_is_list

--Larry Garfield


Oh, I forgot it was accepted and merged, thanks for pointing at it.

Cheers,

Pierre

Re: [PHP-DEV] Two new functions array_first() and array_last()

[Pierre]

Le 15/10/2023 à 01:11, Ben Ramsey a écrit :

On Oct 14, 2023, at 16:30, Nikita Popov  wrote:

On Sat, Oct 14, 2023, at 20:00, David Grudl wrote:

PHP lacks two very basic functions for working with arrays:

- array_first() returning the first element of an array (or null)
- array_last() returning the last element of the array (or null)

While PHP has functions that return the first and last keys,
array_key_first() and array_key_last(), it does not have more useful
functions for values.

a) What about reset() and end()?
Programmers "abuse" the reset() and end() functions for this purpose.
The problem is that these functions are used to move the internal
pointer in the array. Which is why they have a name that is
inappropriate when used in the sense of "return me the first element".

Much worse, they shouldn't to be used to get first/last value, because
they have a side effect (i.e. moving the pointer).

Further, in the absence of an element, they return the obsolete false
and not the currently expected null, which can be combined with the ??
operator. In this they differ from the similar functions
array_key_first() and array_key_last().

b) What about $array[array_key_first($array)]?

For such basic functions as returning the first and last item in an
array, there should be a function in the basic package, not a
workaround. Moreover, this requires having the array in a local
variable, since $this->getFoo()[array_key_first($this->getFoo())]
would be very inefficient and possibly incorrect.

c) Two such functions were proposed and rejected during the
array_key_first/last RFC
(https://wiki.php.net/rfc/array_key_first_last)

Yes, that was in 2018. At that time, functions like str_contains() or
str_starts_with() wouldn't have even come into existence, just because
there was an obscure way to do it without them. I believe we've moved
on since then. Today we know how useful it is to use simple,
easy-to-understand methods, both for programmers who write and read
the code.

DG

I'm in favor of adding these.

To add to what you already said, because reset/end modify the array, there's a 
good chance that calling these functions will copy the whole array due to a 
modification you are not actually interested in.

So basically you have the choice between calling end(), which is the wrong 
thing to do semantically and may be slow, or using 
$array[array_key_last($array)], which is rather convoluted, and incorrect if 
the array is potentially empty.

Regards,
Nikita

I’m in favor of these functions, for all the same aforementioned reasons.


Yes please !

array_first() and array_last() are definitely needed. I wrote `foreach 
($foo as $value) break;` too many times in my life. array_key_first() 
and array_key_last() I wouldn't use it much, but they'd probably  find 
their use cases as well.


The first two probably only make sense for a numerically indexed array, 
so I guess that array_is_list() (whatever the name is, I don't want to 
bikeshed about naming) would be a good addition as well, that, in my 
opinion, would be pertinent to add at the same time.


Regards,

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Pierre Joye]

On Fri, Oct 13, 2023, 2:01 AM Jordan LeDoux  wrote:

>
>
>
> I believe MPFR is what is used by ext-decimal. The only thing that makes
> ext-decimal a somewhat difficult replacement for BCMath is that one of them
> uses precision and the other uses scale. (Total accurate digits versus
> total significant digits.) Fermat has implementations for both BCMath and
> ext-decimal, while also using GMP. It is much more difficult to control the
> number of accurate digits in ext-decimal than in BCMath, but ext-decimal is
> literally hundreds of times faster. I think, however, that Rudi (the author
> of ext-decimal) was against including ext-decimal in core.
>

it isn't really needed if not at the language level.

scaled basic operations can be (relatively) easily optimized, with an order
of magnitude faster than what bcmath does.

however, the real challenge, imho, is the different uses. That's where rock
solid implementation like mpfr could help, for non basic ops or modes.



> But if you want an alternate implementation for arbitrary precision
> decimals, it is certainly the place that someone should start.
>

for the few areas I needed it, I made my own with add/sub and mul/div with
intrinsics.  very little amount of codes and stable.

I am not completely sure how to cover the different usages, scaled
operations may be a good start and keeping bc math user land compatibility
may not too hard.

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Pierre Joye]

Hi Jordan

On Fri, Oct 13, 2023, 1:24 AM Jordan LeDoux  wrote:

>
>
> On Thu, Oct 5, 2023 at 5:27 AM Saki Takamachi  wrote:
>
>> Hi, Pierre
>>
>> In fact, I predict that many use cases will be covered by GMP.
>>
>> Still, I think that there may be cases where calculation functions like
>> mainframe BCD are required, such as when calculating money.
>>
>> I am unable to decide whether it is correct to deprecate BCMath and only
>> use GMP.
>>
>> I'd like to hear other people's opinions as well.
>>
>> Regards.
>>
>> Saki
>>
>
> GMP cannot be used in any reasonable way to implement things like sin() or
> cos(). It is *technically* possible, but not at all reasonable.
>

it is the reason I mentioned mpfr,
https://www.mpfr.org/mpfr-current/mpfr.html#Miscellaneous-Functions

the challenge I noticed in a couple of threads recently is the mixup of
radically different usages, like financial numbers with basic ops (+/-
eventually *//) and others.

they cannot use the same tools, most of the times. However there are libs
with different types or mode of operations, which could be a better fit
than what we do now.

It is not an easy research and priorities need to be clear.

BCMath is one of the worst and slowest implementations of arbitrary
> precision decimals.
>

what I was trying to express  :)


best ,

>

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Pierre Joye]

Hi

On Wed, Oct 4, 2023, 6:39 PM Saki Takamachi  wrote:

> Hi, Marc, Pierre
>
> Thank you for all the information.
>
> After all, I feel that BCMath and GMP have different roles.
>
> Arbitrary precision mathematics and very high precision mathematics are
> similar but distinctly different.
>

I replied about the FP specific question as it can be confusing. Adding
that gmp* may be a more sustainable solution as it is actively maintained
and widely used.

If PHP has already started integrating these things, then of course I'll
> follow suit, but if not, I'm against these integrations.
>
> If I missed something important, could you please let me know?
>

theoretically I agree, both may have different uses. Practically, and
within php ecosystem, they are used for the same purposes.


best,
Pierre

>

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Pierre Joye]

On Tue, Oct 3, 2023, 4:13 PM Saki Takamachi  wrote:

> yes, they do, as do almost all floating points implementation.
>
> Memory limited float values and their respective operations are still
> useful in many areas, but financial values and the likes. Scaled integers
> are the way for accuracy.
>
>
> Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
> accurate FP operations
>
>
> Hi
>
> This seems to be a floating point number with extremely high precision
> compared to regular long doubles. However, as you say, even though the
> accuracy is very high, errors still occur. (the error is so small that it
> almost never becomes a problem.)
>
> By its very nature, BCMath does not introduce any errors. It is debatable
> whether floating point calculations in GMP can play the role of BCMath.
>

so does gmp. The point made about gmp earlier is more about the
sustainability of gmp vs bcmath.

Re: [PHP-DEV] [RFC] [Discussion] Adding bcround, bcfloor and bcceil to BCMath

[Pierre Joye]

On Tue, Oct 3, 2023, 12:25 PM Saki Takamachi  wrote:

>
> I thought GMP was a function for integers, so I wasn't expecting that tbh.
>
> However, even if GMP supported floating point numbers, wouldn't it end up
> having the inherent error problem of floating point numbers?
>

yes, they do, as do almost all floating points implementation.

Memory limited float values and their respective operations are still
useful in many areas, but financial values and the likes. Scaled integers
are the way for accuracy.


Also, side note, gmp recommends to rely on https://www.mpfr.org/ for
accurate FP operations


best,

>

[PHP-DEV] Re: Security Audit Priorities

[Pierre Joye]

Hello,

On Mon, Sep 25, 2023, 3:49 PM Derick Rethans  wrote:

> .
>
> Typical areas would be where user input can be (automatically read)
> remotely, such as
> our RFC 1867 HTTP header parser. But we are sure there are other
> important areas as well, and we would like your input.
>
> So, if you can suggest an area where doing an external review would have
> high impact, please reply to this email.
>

thanks for the feedback request :)

the sapi in general (and the underlying used APIs, like http headers you
mentioned) would be on top on my mind.

The embedded sapi may take more importance soon I think. It won't be as
wide as fpm but frankenphp (or similar) will see a significant increase in
usage, for good reasons:)

best,
Pierre

>

Re: [PHP-DEV] A new JIT engine for PHP-8.4/9

[Pierre Joye]

Hello :)

Posting again, I just realized I used "reply" not "reply all"

On Mon, Sep 11, 2023 at 4:29 PM Dmitry Stogov  wrote:
>
> Hi internals,
>
> I'm glad to present a new JIT engine that is going to be used in the next
> major PHP version. Now it's a real optimizing compiler with Intermediate
> Representation similar to Java HotSpot server compiler.
>
> It makes a base for future improvements and eliminates many low-level
> details of the existing PHP JIT. Instead of supporting assembler code for
> different CPUs, now PHP generates a single IR and passes it to a
> PHP-independent JIT engine.

Great work! This is a massive jump for PHP. Thank you :)

I don't have much concerns about the license etc as the ZE is already
under Zend the ZE license (never updated since Perforce acquired them,
tho'):

https://github.com/php/php-src/blob/master/Zend/LICENSE

I do really like the IR addition. This opens huge new opportunity, not
only for optimization and JIT but to move forward into bringing new
technology support to PHP (WASM f.e.). There are big challenges and I
am not sure yet it can be ever be fully possible to target WASM.
however, having the ability to do it with a subset of PHP, f.e. some
business logic classes etc., would already be amazing. I can't imagine
a php9 without taking this into account tbh. That would be kill php in
any way but that would definitively puts it in less competitive area
than others (JS, go, rust, ocaml f.e.), for another few years.

I have a simple php function working (just a small go app to parse the
IR text output and convert it. But that's not remotely a POC :). I
discussed with Dmitry and the idea would be to add a WASM target to
libIR (partial support or whatever is possible).

This is the part I would like to see more discussions or feedback as
it will define what could become possible or not. A certain level of
similarity or compatibility could make other targets much easier.

> The old JIT implementation is going to be kept for a while.

I like the idea too. The sooner this work can be available as
experimental, the sooner it will get stable.

Best,
-- 
Pierre

@pierrejoye

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Pierre]

Le 11/07/2023 à 17:16, Robert Landers a écrit :

On Tue, Jul 11, 2023 at 4:36 PM Larry Garfield  wrote:

You have to check your vendor folder for an interface, or trait, or abstract 
class.  That doesn't change anything.

As noted, now consider a Baz interface.  For interface-and-trait, you add 2 
more definitions.  For interface-with-defaults, you add 1.  For abstract 
classes, you need to add 4: BazBase, FooBazBase, BarBazBase, and FooBarBazBase.

I guess I don't understand what the interface is solving if you're
creating an interface _and_ a trait, why not just create the trait? It


What's solved here is that you simply don't have to create the trait 
anymore, in this specific use case, no more, no less. And I do like it.


You may not see the point for it, but as a recurrent user of the 
interface+trait from another package, it does bothers me a lot because 
it's never clear about the intent when you don't know the trait exists. 
Having the interface default methods makes it self-documenting and much 
clearer for the user.


There's nothing complex here, it's pure sugar candy, and much 
appreciated one by many I guess.



sounds like you're coupling your interface to a specific
implementation and trying to get multi-inheritance out of PHP. This
seems like a design issue, and this RFC seems like a back-way to
multiple inheritance. Why not just allow multiple inheritance?


Regarding the "back-way to multiple inheritance", it's true, and that's 
how lots of languages that were not design with multiple inheritance in 
mind solves it, such as Java, and I personally find this rather elegant.


--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Interface Default Methods

[Pierre]

Le 03/07/2023 à 13:32, Michał Marcin Brzuchalski a écrit :

I voted "yes", my personal use case waits for this feature. My use
case example:

https://gist.github.com/brzuchal/89e9481bbd34a6ce3d95a68eabff038b

With interface default methods I'd no longer need traits that implement a
single or in rare cases 2 methods that
use their respective methods returning objects and iterate in Generator
fashion over a paginated result set.
This is not an issue if there is one implementation of the interface but
when I decorate to apply some:
* caching
* logging
* failover

then the trait has to be attached to every class besides that it has to
exist which is an additional symbol here.

Cheers,
Michał Marcin Brzuchalski


Please everyone yes to this !

I use Symfony daily, and the SomethingAwareInterface / 
SomethingAwareTrait is very annoying, by having default method 
implementations on interfaces, it would remove the use of having traits 
at all. Everything would be much easier to read and write.


LoggerAwareInterface would no longer require us to use LoggerAwareTrait 
on every class, etc...


This is kind of sugar candy I'd really love.

Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Proposal: addition of array_find() and array_find_key() functions

[Pierre]

Le 02/06/2023 à 10:57, Janusz Szczypka a écrit :
You are right about speed penalty for using those functions over 
simple loops, however if we would stick to that point of view, we 
should deprecate and remove array_filter, array_map, array_walk, 
array_u...


I'm not sure they deserve deprecation, but I think that proposal may be 
the right time to talk about adding a real iterable API in PHP core for 
every one to use, a complete and consistent one, that would work on all 
traversable data structures, https://github.com/nikic/iter is perfect in 
my opinion for a good start, and would really deserve to be in SPL, and 
maintained along with core, and be usable without any composer dependencies.


PHP is really lacking a complete enumerable / iterable / traversable 
API. Maybe this is time to design and add one ?


--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] path_join function

[Pierre du Plessis]

On Wed, 17 May 2023 at 18:24, Gunnard engebreth  wrote:

>
> > Maybe im missing something here but the already available `dirname()`
> does this. right?
> https://www.php.net/manual/en/function.dirname.php
>
>
dirname just traverses up the directory, it doesn't join paths.

For example, this example won't be possible with dirname:

path_join('/root', '/foo\\bar/baz', '../test', 'file.json'); // =>
/foo/bar/test/file.json

Re: [PHP-DEV] Future stability of PHP?

[Pierre Joye]

On Tue, Apr 11, 2023, 1:30 AM Deleu  wrote:

>
>
> I resent the sentiment of "if your code or development process was exactly
> like mine you wouldn't be here complaining" and I believe nobody is asking
> PHP to freeze. Not everyone has the ability to fix every deprecation within
> a couple of hours and not everyone has tests. Yes, we get it, it's common
> knowledge nowadays that code without test is unmanageable, but if you
> inherited a 15 year old codebase developed by multiple developers in a
> start-up mentality
>


This is wrong in so many levels Agility mindset, startup or not, does not
prevent to do the required cleanups.

These, by the way, are yearly,  worst case.

producing code faster than they could actually plan for and with no tests,
> its going to take some time to clean that up and if I take longer than you
> would, does it mean I matter less as a PHP user?
>
> PHP 8 is pretty great to work with and a lot better than previous
> versions, but there was no opt-in aspect to a lot of PHP breakages. All
> that we're asking here is for a bit more forgiveness to existing code that
> was developed 2 decades ago by a complete different generation and still
> need to run today while we clean it up.
>


Many things that will actually break codes (removal of features f.e.), have
been deprecated for years.

as it has been mentioned, many distributions provide longer support for
older php versions.

If you want the latest php version, you will have to prepare for it,
constantly and changing, cleaning your code constantly.  This is done as
part of the daily feature additions, no need to ask a PO or whoever else,
just add it to your estimates (if you still use them).

However, asking, as nicely as you did, the volunteers here to do it for you
as the language level, won't work.

best,
Pierre

>

Re: [PHP-DEV] Moving PHP internals to GitHub

[Pierre]

Le 12/04/2023 à 16:29, Rowan Tommins a écrit :


Reactions are a nice social media feature, but I don't think I've ever seen
them used to convey anything particularly meaningful.

If I write a comment that gets 3 smily faces, 4 angry faces, one rocket,
and one of those weird Japanese fireworks, all from people who haven't
otherwise participated in the conversation ... I'll just ignore them and
carry on.

It's certainly not a killer feature I'd uproot an entire community for.

Regards,


I sometime wish there was reactions thought. There's ton of message I 
read I'd only wish to say "I agree" without sending a complete email 
polluting the discussion for just this.


A simple up and down count would be great to visually assess how readers 
receipt the message. For long and complex discussions about some 
controversial RFC's this could have some kind of meaning.


It also could allow people to express they like an RFC independently of 
any technical consideration, this could at least give some kind of 
number of people interested in feature X or Y.


I'm not saying this list needs social network features, and I like it 
being as it is, but yes, for RFC, it sure lacks public opinion surveys, 
easy ones I mean, ones that anyone can stumble upon easily and say "I 
want it", "I don't want it" or "I don't care". There are millions of PHP 
developers, and nobody never reaches them to take temperature about how 
useful would be X or Y feature, and that's sad.


I guess some RFC's would probably move faster if the developer that 
tries to push it explicitly knows that hundreds or thousands of people 
are supporting it. It would also give sense to some hard and ingrate 
tasks, and some explicit gratitude, recognition for the work done, it 
could be very positive, and simply nice for the few PHP developers doing it.


That was my 2 cents about all this. Maybe what the thread creator mean 
is simply that the PHP development process is kind of hidden in this 
list, and it's not that easy to reach or read for people, even when 
using https://externals.io/


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Future stability of PHP?

[Pierre Joye]

hello,


On Sun, Apr 9, 2023, 1:37 AM Stephan Soller 
wrote:

> Hello,
>
> I'm sorry if this isn't the correct mailing list for that discussion but I
> couldn't find a more appropriate one where people actually know how the
> wind is
> blowing.
>
> A few days ago I migrated a project from PHP 7.1 to 8.2 and the amount of
> deprecations and fatal errors spooked me a bit (details below if you're
> interested). That got me wondering about the long-term stability of PHP
> (as in
> language and API breaks) and I looked at the RFCs. I got the impression
> that
> static typing has a lot of traction now and I have no idea of what the
> fallout
> might be of changing a dynamically typed language into a statically
> typed one.


I keep reading this in multiple languages, pr even more frameworks.

I understand agency work, managers pushing new features instead of a
cleaning some legacy.

however years of ignoring deprecation notices (very few were introduced
right before 8.0).

Most of them could have been fixed within a couple of hours in any code
base, if they had tests.

I would suggest, very very nicely, to review and rethink the development
flows of these projects instead of asking php to freeze.

best,
Pierre

Re: [PHP-DEV] Windows PECL build machine died

[Pierre Joye]

Hello,

I wonder if we could not use on demand resources for the builds (like
windows gh actions) and use the normal distribution mirrors setup?

Pierre

On Fri, Feb 17, 2023, 8:10 PM JEDI_BC / Bruno CHALOPIN 
wrote:

> Hi
>
> On 11/07/2022 18:25, Christoph M. Becker wrote:
> > On 11.07.2022 at 17:41, Hans Henrik Bergan wrote:
> >
> >> Do you mean it is unlikely that Github Actions will suffice? because
> that
> >> would definitely be a great solution if it was possible/feasible .
> >
> > No.  It is only unlikely that automated uploads to window.php.net will
> > ever be possible using GH actions.
> >
> >> Anyway, with regards to "I don't think there are special requirements
> >> regarding the hardware", can you give a rough estimate on RAM/disk space
> >> requirements?
> >
> > The old machine had something like 4 or 8 GB RAM, and a 128 GB hard disk.
>
> Is there recent development about the situation of the windows pecl
> build machine ?
>
> How can we help ?
>
> Regards,
>
> Bruno CHALOPIN
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Methods which auto-return the class instance

[Pierre Joye]

On Fri, Dec 23, 2022, 7:46 PM joke2k  wrote:

> Thanks for the feedback!
>
> On Fri, 23 Dec 2022, 09:33 Claude Pache,  wrote:
>
> > It is very common for fluent class methods to have a verbose `return
> > $this;` ending in their body.
> > But If you have declared `self` as return type into a non-static class
> > method you have only two options to return:
> >
> > - the $this object
> > - another instance of the same class or subclass
> >
> > ... in order to avoid a return type error.
> >
> >
> > It is still two options, and it is not clear in general which one to
> pick.
> > You could also say that, if you have `object` as return type, there are
> two
> > options to avoid a return type error: either return the `$this` object,
> or
> > return another object.
> >
>
> Yes but declaring `self` is more strict than `object`.
> And talking about the word itself... Declaring to return (your-)`self` but
> you could return someone-else of the same type as you.
> But it is ok, it refers to the class name not the instance. just semantic.
>

I would rather endure it returns the used instance and not another one with
a compatible interface. Not doing do is actually confusing to me, as per
the meaning of self. .

Or maybe, if the goal is to ease declaration of fluent interfaces (methods
chaining), declaring a class fluent (annotation?) would achieve the same
with ambiguous names?

>

Re: [PHP-DEV] Increase maximum size of an uploaded file to 50Mbyte

[Pierre]

Le 10/09/2022 à 11:31, Yasuo Ohgaki a écrit :

2022年9月7日(水) 22:58 Misha :
I can understand the motivation, but I am against the change.

To increase uploaded file max size, POST max size must be increased too.
For 99.99% entry points do not need 50MB POST max size.
and larger POST max size increases DoS risks.

Default upload file max size and POST max size should be small enough value
for better security.
IMHO, PHP script that handles large POST data should increase these
settings.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net


Hello,

Where I work we use a client side component that split files, send them 
chunked, handle progress, resuming etc... along with a server side PHP 
component. This method was originally developed for three reasons: allow 
huge file uploads (videos), give the user a progress bar, and more 
importantly, be able to bypass POST max size restrictions in production 
environments we cannot configure because they're managed by a remote 
external admin team.


My point is, I don't care about default limit remaining 2MB personally 
because we mostly work on products in which chunking files is the 
default. Anyway you also will have limit set at the HTTPd level as well 
if you want to be able to use it fully (in my original case the most 
limiting layer in the HTTP stack was Nginx at the time) having every 
layer in your stack working nicely together regarding POST size is not 
something you will always have in production environment that you don't 
fully manage yourself.


I think that raising the limit to something between 10MB and 20MB is 
something reasonable so that people like me in the future won't be 
forced to develop a client side file chunker for most use (phone photos, 
some PDF files, etc... most commonly), but raising higher may be a 
security issue. My phone takes 4k pics andthey site between 4MB and 
10MB, I think that the default limit doesn't have to be much more than 
this. As soon as you want to let your users upload bigger files, relying 
on a single HTTP POST seems dangerous for all of ergonomics, security 
and performance.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Typed constants revisited

[Pierre]

Le 24/03/2022 à 16:06, Mark Niebergall a écrit :

So you are correct, the const value does have a value that has a type, but
there is no way to enforce which type the value is or to use const with
inheritance, which is part of the bigger picture here.


That was exactly my point: the type could simply implicitely be the one 
of the original value.


Then the engine just has to use the existing covariance/contravariance 
rules for type checks based upon the guessed value type. This would fix 
the type safety issue you are referring to.


--

Regards

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Typed constants revisited

[Pierre]

Le 23/03/2022 à 23:10, Larry Garfield a écrit :

Is there a benefit to it other than "well everything else has types now, so..."?  Even if 
it's esoteric, like in reflection-based meta programming?  (I've been dabbling too much in that 
lately. :-) )  "Everything else does" isn't a compelling argument for me, but there may 
be others I'm not thinking of.

--Larry Garfield


Hello,

Well I was thinking myself that const being well... constant, and so 
always defined, type could be determined at compile time without the 
need to express it in a verbose way.


PHP doesn't do any static type inference, but in this case, it could be 
done almost for free, am I wrong ? If it was determined at compile time, 
then the type checking on overrides would only be trivial, using the 
parent occurrence value inferred type. My point is that there's no need 
to express the type of a value, the value has already has a type.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Discussion: String streams

[Pierre]

Le 22/03/2022 à 16:14, Sara Golemon a écrit :

On Tue, Mar 22, 2022 at 5:38 AM Robert Landers 
wrote:


But why can't we have generic operator overloading in which case this could
be completely built by libraries in userland?


I mean... honestly, I feel like I come back around to this very quickly.
Generic overloading gives us much more at the end of the day and allows the
people using PHP day in and day out to make the actual decisions about what
any of these APIs should look like.

So while I said I wanted to avoid the firestorm suggesting userspace
overloading would bring, maybe that's the question to ask:

Who's just a hard-nope on userspace operator overloading?  If your reasons
go beyond foot-gun (and that is a valid reason), could you share what those
reasons are?

-Sara


Hello,

I am a not so hard-nope against userland operator overloading because 
it's magic. My day job is 20% writing code, 30% speaking with clients, 
and 50% reading and using community code. Userland operators are not as 
explicit as verbose method calls; and you can't ctrl-space an operator 
in any existing IDE, it's not obvious at what they does when you read 
code using them in most cases, and beyond that, in order to use them, 
you have to read an external documentation. Not that I don't read 
external documentation, but 80% of time, reading directly interfaces in 
my IDE is enough to know what to do with an API. When an API uses 
methods for doing stuff, code is auto-documented, when people start 
overriding operator, not so much (at least not as easy to find and 
understand at first sight) especially if the code is segregated behind 
interfaces and those interfaces don't explicit the operators (At least I 
hope that, if userland operators land, that interfaces will have a way 
to explicit the override).


And in the end, operators are just sugar for method calls. I don't 
dislike writing $c = $a->plus($b) instead of $c = $a + $b, I even found 
that there's some kind of elegance behind writing stuff explicitly. 
There's no feature in the world that would be blocked by the lack of 
operator overloading.


Moreover, the << >> c++ style stream operators are no more than a way to 
implement the string builder pattern, if I understand it well. Then why 
can't simply we use a StringBuilder class and use methods such as 
append(), prepend() and all ? It's much more explicit and much less 
alien-like for most people.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Under discussion] Arbitrary string interpolation

[Pierre]

Le 18/03/2022 à 15:02, Chase Peeler a écrit :

On Fri, Mar 18, 2022 at 12:49 AM Theodore Brown 
wrote:


On Thu, Mar 17, 2022 at 5:40 PM Tobias Nyholm 
wrote:


On Thu, 17 Mar 2022, 23:27 Ilija Tovilo,  wrote:


Hi everyone

I'd like to start discussion on a new RFC for arbitrary string
interpolation.
https://wiki.php.net/rfc/arbitrary_string_interpolation

Let me know what you think.

That is a cool idea.
But I am not a big fan of having code in strings.
Wouldn’t this open the door to all kinds of new attacks?

Do you have an example of a new kind of attack this would allow?
The proposal doesn't enable interpolation of strings coming from
a database or user input - it only applies to string literals
directly in PHP code.

Personally I'm really looking forward to having this functionality.
Just a couple days ago I wanted to call a function in an interpolated
string, and it was really annoying to have to wrap the function in a
closure in order to use it.

If this RFC is accepted I'd be able to replace code like this:

 $name = "Theodore Brown";
 $strlen = fn(string $string): int => strlen($string);
 echo "{$name} has a length of {$strlen($name)}.";

with

 $name = "Theodore Brown";
 echo "{$name} has a length of {$:strlen($name)}.";



Out of curiosity, why not:
$name = "Theodore Brown";
echo "{$name} has a length of ".strlen($name).".";

or even
$name = "Theodore Brown";
$len = strlen($name);
echo "{$name} has a length of {$len}.";


I guess it's a matter of taste and convention.

Sometime, it make sense and it's just easier to just use string 
interpolation (for example with multiline templates).


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Pierre Joye]

On Sat, Mar 5, 2022, 10:31 AM Kris Craig  wrote:

> On Wed, Mar 2, 2022 at 4:51 AM Marco Pivetta  wrote:
>
>
> But that doesn't mean we should be using the PHP website to start taking
> sides in military conflicts.
>

There is no side to take but the population in Ukraine, friends, family,
colleagues as well as in Russians, the victims of a dictatorship' lies.

I don't see any issue to show our support for them, quite the opposite, I
do see an issue not to show it. A link to red cross and other ong
supporting refugees and civilians is not political, it is being a human.

It does not mean we take a political side. As much as there is not much to
discuss about that, but the deconstruction,  point by point, of every
single claim to justify this invasion, but php.net is not the place for
that.

best,

>

Re: [PHP-DEV] Setting to disable the "Undefined array index" warning

[Pierre]

Le 15/02/2022 à 13:46, Thomas Nunninger a écrit :

Hi Nicolas,

as far as I understand, adding new ini settings is not the way to go 
as this would mean that your code behaves differently on different 
environments.


Two suggestions:

* Write your own error handler that ignores those errors.

* Try some tool like Rector to rewrite your code.

Best regards
Thomas


Hello,

I do agree with Thomas here, changing PHP internal behavior by 
configuration is a dangerous thing to do.


If I understand correctly, there is "more than 130 000 lines of PHP 
code" to fix, believe me I migrated a few projects along the way from 
PHP 5.6 to 8.0 over time (one was about this size, but it stopped at PHP 
7.0 a few years back). They probably contain less "legacy code" since we 
have strict conventions from the beginning, but we did migrate some 
projects still.


Fact is, a legacy project cannot run without evolving if you want to 
support a recent PHP version. The language itself evolves, and that's 
for the best. Now for really legacy unmaintained projects, there's still 
the solution to keep them running on deprecated PHP version using some 
container technology. It's not ideal, but it can help until you finally 
find the necessary resources to port.


Using a good static analysis tool and possibly some other tools such as 
Rector, 130k lines is not an impossible goal.


I don't think there's an easy solution here, it's either don't upgrade, 
or either refactor, but modern tooling should help you a lot with that.


If it can help you, can can still replace your array access using `$a = 
$foo['bar'] ?? null` instead of `$a = \array_key_exists('bar', $foo) ? 
$foo['bar'] : null`, it's both easier to read and write (you just store 
` ?? null` in your clip board and hit paste on every use case you find).


Hope it helps,

Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Github issues

[Pierre Joye]

On Mon, Feb 14, 2022 at 1:02 PM Marco Pivetta  wrote:
>
> 1. You need to be part of https://github.com/orgs/php/people
> 2. Your group must have issue triage rights

Thanks Marco, I know what can be done in github, I do not know who I
have to ping here to get that done as I cannot add myself to the
organization. The organization was limited when gh was only a mirror,
so I wonder why all accounts did not get migrated.

-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Github issues

[Pierre Joye]

Hi,

What has to be done that the github issues can be handled by the same
developers than in bugs.php.net?

It is a bit weird that I cannot change status or anything else but add
comments :)


Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Multibyte strings

[Pierre Joye]

good morning,

On Sat, Feb 12, 2022, 3:47 AM Rowan Tommins  wrote:

> On 11/02/2022 18:42, Michał wrote:
> > Considering the given example, the description from the documentation
> > of strlen function: "Returns the length of the given string".
>
>
> Which is exactly what it does. Using Unicode terminology [see
> https://unicode.org/glossary], here are a few different things you could
> count to determine the "length" of a string:
>
> a) bits
> b) bytes
> c) code units (UTF-16 has code units of 16 bits, UTF-8 has code units of
> 8 bits)
> d) code points (one of 1,112,064 numbers that can be given a meaning by
> the Unicode standard)
> e) graphemes (what a user would generally think of as a "character")
> f) pixels (or any other unit of physical size)
>

it is why we have intl, which uses the ICU and allow users to update it.
That means using the latest standard if needed.

best,
Pierre

>

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Pierre Joye]

Hi Tim,

On Tue, Jan 11, 2022 at 4:40 PM Tim Düsterhus, WoltLab GmbH
 wrote:
>
> Hi Pierre
>
> On 1/11/22 4:48 AM, Pierre Joye wrote:
> > Also sensitive data goes way beyond arguments, GDPR brings a lot of
> > issues here too. Userland packages like monolog provide filters or
> > custom output, I think that is where it should be handled.
>
> I believe that the author of a function is in the best position to
> decide whether a specific argument generally holds sensitive data or
> not. This avoids every exception handler / logger / … having to check
> what function parameters hold sensitive data and scrubbing them,
> possibly missing some.

You are fully correct here.

My thoughts differ as I think there are better tools to handle this
than PHP itself, as well as all other cases where sensitive data may
be exposed (a lot more than backtrace, which is handled already using
the ini setting).
Things like query errors, etc. There is no way we can handle them all
and this is really the developer responsibility to handle this data in
a safe manner. We do our best at the engine level for critical data
from an engine point of view. Application level critical data are the
developers responsibility (config, code, etc.).

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] RFC [Discussion]: Redacting parameters in back traces

[Pierre Joye]

Good morning Tim,

On Mon, Jan 10, 2022 at 9:06 PM Tim Düsterhus, WoltLab GmbH
 wrote:

I am not sure it makes sense to make the code so verbose to prevent
users from showing sensitive data as it never stops (next
print_r/var_dump and userland version of them?).

Also sensitive data goes way beyond arguments, GDPR brings a lot of
issues here too. Userland packages like monolog provide filters or
custom output, I think that is where it should be handled.

As a side note, the RFC mentions that zend.exception_ignore_args may
not be configurable on some shared hosters, it is INI_ALL, so even in
the code could change it, any time, back and forth:

http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] (Planned) Straw poll: Naming pattern for `*Deque`

[Pierre Joye]

Hi Tyson,

On Tue, Sep 21, 2021 at 9:19 AM tyson andre  wrote:
>
> While there is considerable division in whether or not members of internals 
> want to adopt namespaces,
> I hope that the final outcome of the poll will be accepted by members of 
> internals
> as what the representative of the majority of the members of internals
> (from diverse backgrounds such as contributors/leaders of userland 
> applications/frameworks/composer libraries written in PHP,
> documentation contributors, PECL authors, php-src maintainers, etc. (all of 
> which I expect are also end users of php))
> want to use as a naming choice in future datastructure additions to PHP.
> (and I hope there is a clear majority)
>
> -
>
> Are there any other suggestions to consider for namespaces to add to the 
> straw poll?
>
> Several suggestions that have been brought up in the past are forbidden by 
> the accepted policy RFC 
> (https://wiki.php.net/rfc/namespaces_in_bundled_extensions)
> and can't be used in an RFC.
>
> - `Spl\`, `Core\`, and `Standard\` are forbidden: "Because these extensions 
> combine a lot of unrelated or only tangentially related functionality, 
> symbols should not be namespaced under the `Core`, `Standard` or `Spl` 
> namespaces.
>   Instead, these extensions should be considered as a collection of different 
> components, and should be namespaced according to these."
> - More than one namespace component (`A\B\`) is forbidden
> - Namespace names should follow CamelCase.

Besides the namespace thing (collection is fine imho). What is the
reason to have it final?

For collection in general, would it make sense to have a common
interface representing the minimum expected API? If possible, then
algorithm specific on top? a bit like we have with the traversable
interface and related.

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre Joye]

Hi Nikita,

On Tue, Jan 4, 2022 at 12:38 AM Nikita Popov  wrote:
>
> On Mon, Jan 3, 2022 at 1:14 AM Jordan LeDoux 
> wrote:
>
> > Hello internals,
> >
> > I've opened voting on
> > https://wiki.php.net/rfc/user_defined_operator_overloads. The voting will
> > close on 2022-01-17.
> >
> > To review past discussions on this RFC and the feature in general, please
> > refer to:
> >
> > - https://externals.io/message/116611 | Current RFC discussion
> > - https://externals.io/message/115764 | Initial RFC discussion
> > - https://externals.io/message/115648 | Pre-RFC discussion and
> > fact-finding
> >
> > Jordan
> >
>
> Voted No on this one. I did support the previous proposal on this topic,
> but I don't like the changes that this iteration has introduced relative to
> the previous proposal.
>
> The part that I dislike most (and that I consider an exclusion criterion
> regardless of any other merits of the proposal) is the introduction of a
> new "operator +" style syntax. I found the motivation for this choice given
> in the RFC rather weak -- it seems to be a very speculative
> forward-compatibility argument, and I'm not sure it holds water even if we
> accept the premise. There's nothing preventing us, from a technical
> point-of-view, from allowing the use of some keyword only with magic
> methods. On the other hand, the cost of this move is immediate: All tooling
> will have to deal with a new, special kind of method declaration.
>
> I'm also not a fan of the OperandPosition approach, though I could probably
> live with it. The previous approach using static methods seemed more
> natural to me, especially when it comes to operators that do not typically
> commute (e.g. subtraction).

I hesitated too, however I think we can't escape this feature. Like it
was for the annotation, we need to find a compromise.

Your points are valid so I wonder if the RFC could be modified and get
to the point we could reach that compromise. There will be the
oppositions for the features as a whole, however I am optimistic about
our abilities to get there this time rather than wait yet again a few
years for something we know we will have anyway.

Best.
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 2:17 AM Pierre Joye  wrote:

>
>
> On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:
>
>> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>>  > might be okayish, though.  ICU ships a VS solution file
>>  > (source/allinone/allinone.sln) which works fine.  I don't know
>>  > whether using that would be okay for Conan.
>>
>> No need to worry about that, it's just a way to coerce ICU's build
>> system into behaving well on Windows. Conan uses Msys2 as a build
>> environment for projects with *nix lock-in, which produces native
>> binaries without the cygwin shenanigans.
>>
>
> what does it mean exactly here?
>
> it uses msys for autoconf and co support but actually uses vc? or it
> relies on gcc and co?
>


rt*m :)

it can use whatever is needed and prioritization of cmd in the paths is
supported, neat  :)

https://docs.conan.io/en/latest/systems_cross_building/windows_subsystems.html

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Jan 4, 2022, 1:35 AM Horváth V.  wrote:

> On 2022. 01. 03. 18:17, Christoph M. Becker wrote:
>  > Oh, that would be an issue.  We can't use Cygwin builds; MinGW builds
>  > might be okayish, though.  ICU ships a VS solution file
>  > (source/allinone/allinone.sln) which works fine.  I don't know
>  > whether using that would be okay for Conan.
>
> No need to worry about that, it's just a way to coerce ICU's build
> system into behaving well on Windows. Conan uses Msys2 as a build
> environment for projects with *nix lock-in, which produces native
> binaries without the cygwin shenanigans.
>

what does it mean exactly here?

it uses msys for autoconf and co support but actually uses vc? or it relies
on gcc and co?

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I forgot to answer to that, specifically. I'd much more prefer to have 
an explicit `equals(object $other): bool` (magic or not, really I do not 
care) single method for equality only, that'd be great. In that sense, I 
much preferred specific RFC about `__equalsTo()` or `__compareTo()` 
alone that a huge generic operator overload RFC. I think both could 
actually be separated, it wouldn't be that weird.


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 17:12, Larry Garfield a écrit :

On Mon, Jan 3, 2022, at 9:52 AM, Pierre wrote:


I personally tend to agree with everything that Marco said. Especially
regarding the fact that it's adding huge complexity to the language
itself for mostly edge cases.

I'd argue there's many much more valuable features that could be added
to PHP before operator overload, such as generics, rationalized
collection API and scalar objects with methods for example (which all
could be magnificent tools for improving the operator overload RFC).

Those are all independent of operator overloading.  There's zero reason one 
needs to come before/after any other.  Everyone wants generics, but they're 
really hard or Nikita would have implemented them already.  This is a 
non-argument.

Also, people keep talking about edge cases.  In my experience, "are these two 
objects equal" (for some object-specific definition of equal) is very much *not* an 
edge case.  I may have less use for overloading % as I don't use advanced math that much, 
but I compare things all the frickin' time and that would be incredibly useful day to day.


I think you read it too quickly. Anyway it was just examples, my point 
is not specifically about generics, but about the fact that operator 
overloading has been hugely controversial, and independently of the fact 
that I think this is a very well documented RFC, I still don't like it 
and express my opinion, I probably would not use those, but I eventually 
will be step debugging into some, and god, I don't wish I'll have to, 
really, I hate magic and non verbose code. Nevertheless, I have to 
admit, if I had the right to vote, I would abstain because it still a 
feature a lot of people want.


Best regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] User Defined Operator Overloads

[Pierre]

Le 03/01/2022 à 16:00, Marco Pivetta a écrit :
I'd probably use `$ts1->subtract($ts0)`, which doesn't seem to be that 
unreadable, and there is no need to abbreviate it to "diff" either.
Whether it needs to be static methods or instance methods depends on 
the wished API design.


What this RFC aims at is a mathematical language, inside another 
general purpose language: for complex expressions, I'd probably run it 
in a subsystem dedicated to this instead.


See for example:

 * https://en.wikipedia.org/wiki/Expression_(mathematics) (I'm 
literally just picking a complex example - don't even know how to read 
that properly)
 * and its textual representation in 
https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)&action=edit§ion=1 
<https://en.wikipedia.org/w/index.php?title=Expression_(mathematics)&action=edit§ion=1>


```php
$expression = <<<'MATH'
f(a)+\sum_{k=1}^n\left.\frac{1}{k!}\frac{d^k}{dt^k}\right|_{t=0}f(u(t)) 
+ \int_0^1 \frac{(1-t)^n }{n!} \frac{d^{n+1}}{dt^{n+1}} f(u(t))\, dt.

MATH;

$result = $userlandExpressionEngine->evaluate(
    $expression,
    [
 // ... bind parameters here 
    ]
);
```

Heck, I can probably ask the `$userlandExpressionEngine` to render 
that monstrosity for me (see attachment).


Note that we do this stuff constantly for SQL, yet we haven't designed 
a system for embedding SQL into the language, and still, SQL is used 
many magnitudes more than all what was discussed in this RFC.


Yes, strings are problematic to some degree, but it's still better 
than increasing language complexity for a very edge case.


Alternatively, a better way to embed other languages can be used, 
which would be much more useful for things like Twig, Blade, PHPTal, 
SQL, etc: In haskell, this is done via Template Haskell, which many 
like, and many loathe, but is still useful for type-safe operations 
with a different language than the "main" one: 
https://wiki.haskell.org/A_practical_Template_Haskell_Tutorial#Shakespearean_Templates


In addition to all the above, I just noticed that the entire 
reflection API in the RFC requires major BC breaks in the reflection 
API... sigh.


Marco Pivetta


Hello,

I personally tend to agree with everything that Marco said. Especially 
regarding the fact that it's adding huge complexity to the language 
itself for mostly edge cases.


I'd argue there's many much more valuable features that could be added 
to PHP before operator overload, such as generics, rationalized 
collection API and scalar objects with methods for example (which all 
could be magnificent tools for improving the operator overload RFC).


I'm not against explicit method call, it's both readable and navigable, 
whereas operator overload tend to magically hide what the code really does.


Best regards,

--

Pierre

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

good evening Horváth,

On Thu, Dec 30, 2021, 11:49 PM Horváth V.  wrote:

> Like I said in another e-mail, I wish to work on my host OS and this is
> something that would need to be done either way. It won't take me long
> either and PHP has been chugging along nicely so far without CMake.
>
> vcpkg has more dependencies missing than Conan and Conan has the
> advantage of providing pre-built binaries. For vcpkg, Open LDAP is
> missing, Cyrus SASL is missing, Bison is missing, Flex is missing, etc.
>

excellent,  Conan it is then  :)




> After New Year's, I will get to grinding out the dependencies that are
> missing in Conan and depending on how fast my PRs are accepted to CCI, I
> may be able to start working on PHP itself in February. Most of the time
> will be taken up by adjusting documentation, PHP provided tooling for
> extensions and gathering feedback from existing extension developers, so
> there is no reason to hurry.
>
> I think I will create a summary issue on the Conan Center Index
> repository with checkboxes to track my progress. Please look forward to
> that and consider subscribing to that issue if you are interested.
>


I will definitely follow it and see what can be done in pickle to support
it as well as the legacy build system.


thank you for pushing it forward, much needed  :)

best,
Pierre

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Wed, Dec 29, 2021, 8:02 PM Christoph M. Becker  wrote:

> On 29.12.2021 at 13:38, Horváth V. wrote:
>
> > Just a quick update on this in between the holidays.
> >
> > There are indeed quite a few of the libraries provided in the php-src's
> > Windows SDK that are missing from Conan Center Index, which is the
> > default remote when fetching dependencies using Conan.
> >
> > I have submitted a recipe for WinEditLine and it is pending review by
> > the Conan team. I am basically done with OpenLDAP's recipe as well, but
> > it needs Cyrus SASL as a dependency, which does not build on Windows
> > using the CCI recipe yet.
> >
> > Ironically, many of PHP's dependencies use Autotools as their build
> > tool, which makes it practically impossible to build them cross
> > platform, so I have to rewrite things in terms of CMake :)
>
> Right!  This is why I suggested to postpone Windows support for now. :)
>
> The core dependencies for Windows builds are currently hosted at
> ; some can be built using
> .  Of course, it would
> preferable to be able to build all the libs with CMake, instead of the
> current mix of self made or provided Makefiles, Visual Studio solutions,
> and what not.
>

I would rather separate external libs challenges from the php cmake move.
CMake macros allow all kind of detection anyway, pkgconfig or custom.


 Conan looks good while I never tried it. There are other, *nix only, or
win and unix, ie vcpkg which has all php deps afair.

Also cmake is for php, I would prefer to move away from our custom builds
scripts for external libs on windows,  very hard to maintain and not
scalable.


best,

Re: [PHP-DEV] Drop support for libmysql with mysqli

[Pierre Joye]

On Sat, Dec 25, 2021, 10:29 PM Remi Collet  wrote:

> Le 24/12/2021 à 18:32, Kamil Tekiela a écrit :
> > Hi Internals,
> >
> > I would like to propose dropping support for libmysql from mysqli and ask
> > for opinions on how this could be best achieved.
>
> +1 to drop support for libmysql.
>

+1 too while the ones maintaining it may have something to say :)

P.S. one more point, IIRC License is not compatible
> with php one (GPL) despite there is a FOSS exception
> for Linux.
>

+libmysql, just in case :)

best,
Pierre

>

Re: [PHP-DEV] Re: PHP-FPM process management woes

[Pierre Joye]

On Thu, Dec 23, 2021 at 5:32 AM Christoph M. Becker  wrote:
>
> On 22.12.2021 at 22:44, Jakub Zelenka wrote:
>
> > After thinking about this a bit more I think we would still need some way
> > to provide the current functionality of the MINIT if that's moved on child
> > level. The problem with not having such step is that opcache shm would be
> > then segmented between children - each child process would have its own shm
> > so it means that it would likely break things like opcache_reset that would
> > work only for a single child but wouldn't have any impact on other
> > children.
>
> I think the children could still re-attach to OPcache (like on Windows),
> and that might not even be that bad as on Windows (where ASLR can break
> that).  However, forking late might break preloading (not sure), and
> generally re-attaching isn't the nicest solution.

I remember some similar issues a while back. I wonder if it could make
sense to separate these two flows.

The MINIT is critical to many extensions, not doing fancy things like
OpCache or similar. Would it be possible to split them? One actual
MINIT (as per doc, once per process) and one for more fancy stuff like
what is done in OpCache (or apcu afair)? I can't think of another way
to make the MINIT/SHUTDOWN API behave as it should while being
designed before fpm came to life. Or we let the ext developers handle
it themselves by providing some helpers function about the current
stage the ext is in (root process or childs) but that will be painful
to do and port.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Dec 21, 2021, 5:24 AM Christoph M. Becker  wrote:

> On 20.12.2021 at 23:01, Horváth V. wrote:
>
> > On 2021. 12. 20. 17:19, Pierre Joye wrote:
> >
> >> We may switch to vcpkg distributions, [...], or the current autoconf
> >> php js port works too.
> >
> > Could you elaborate on what you mean by these?
> >
> > The reason why I prefer Conan here is because they provide pre-built
> > binaries for common setups, so that makes builds go faster for the
> > majority of the cases. I'm not against having a vcpkg manifest either
> > way, since that's just a simple JSON file at the root of the project,
> > but that will result in duplication and one more thing to maintain.
>
> I assume that Pierre was referring to the Windows dependency libraries.
>
> Anyhow, I suggest to defer the Windows support; it appears to be more
> important to have a CMake based build system working for other platforms
> first, and then we can still figure out how to make that useable on
> Windows, too.  In other words, eating the elephpant one bite at a time. :)
>


actually better to do it together or closely.

Cross compilation works, or miltiplarform too. But doing it late is a pain.

Also, I did not check which platforms are currently supported by cmake but
it was the main reason back then to stick to autotools.

And btw, vcpkg is only about dropping our own builds for all libraries
needed.  :)


best,
Pierre

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Tue, Dec 21, 2021, 5:02 AM Horváth V.  wrote:

> On 2021. 12. 20. 17:19, Pierre Joye wrote:
> > We may switch to vcpkg distributions, [...], or the current autoconf
> > php js port works too.
>
> Could you elaborate on what you mean by these?
>
> The reason why I prefer Conan here is because they provide pre-built
> binaries for common setups, so that makes builds go faster for the
> majority of the cases. I'm not against having a vcpkg manifest either
> way, since that's just a simple JSON file at the root of the project,
> but that will result in duplication and one more thing to maintain.
>


I meant the current autoconf port (using js) on windows works perfectly
with vcpkg.

best,

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Pierre Joye]

On Tue, Dec 21, 2021, 6:37 AM Andreas Hennings  wrote:

>
> In a class Matrix, you might want to implement three variations of the
> * operator:
> - Matrix * Matrix = Matrix.
> - Matrix * float = Matrix.
> - Matrix * Vector = Vector.
> Same for other classes and operators:
> - Money / float = Money
> - Money / Money = float
> - Distance * Distance = Area
> - Distance * float = Distance
>

these are bad examples and nightmare to maintain. I think even more with
lovely typed languages. Matrix*float are better implemented as method here.

>

Re: [PHP-DEV] Surveying interest regarding CMake

[Pierre Joye]

On Fri, Dec 17, 2021, 10:23 PM Kalle Sommer Nielsen  wrote:

> Hi
>
> Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. <
> friendlyan...@hotmail.com>:
> > Yes, gradually phasing the current build system out is the most
> > pragmatic choice, although it will incur some extra maintenance cost for
> > the time it's still in use, but it's better to do something sooner than
> > later. This will also allow php-src to drop the Windows SDK altogether
> > that was recently moved to the GH org, because Microsoft stopped
> > maintenance.
>
> I feel it is important to clarify something here. The Windows SDK is
> still supported by Microsoft. The Binary SDK for PHP by Microsoft
> which is the SDK that manages dependencies and provides cross MSVC
> environment build scripts is no longer supported.
>
> You can still build PHP on Windows without the Binary SDK but you will
> have to manage the build depedencies in all their flavors manually
> without this Binary SDK for PHP.
>

We may switch to vcpkg distributions, which supports cmake out of the box
as well, or the current autoconf php js port works too.

best,

>

Re: [PHP-DEV] [RFC] User Defined Operator Overloads (v0.6)

[Pierre]

Le 16/12/2021 à 05:01, Jordan LeDoux a écrit :

This is not a use case I highlighted because it's one that would be
difficult to support with this RFC. But as you say, it could be a good
future expansion. In particular, putting a query builder object into core
with some more advanced overloads built in may be the best way to
accomplish this, particularly if it is built with the idea in mind that the
entities themselves may also have overloads.

I can certainly add it to the future scope of this RFC however.

--

RE: The operator keyword and operator implementations being non-callable.

This was a limitation that I purposely placed on the operator keyword, as I
didn't like the idea of allowing syntax of the style `$obj->{'+'}();` or
`$obj->$op();` and I wanted developers to clearly understand that they
shouldn't treat these as normal methods in the vast majority of
circumstances. However, it seems this is one of the largest sticking points
for those who would otherwise support the RFC. To that end, I'm considering
removing that restriction on the `operator` keyword. If I were to do that,
you'd no longer need to wrap the operator in a closure to call it, though
the parser would still have problems with `$obj->+(...);`

I suppose my question then would be, is this an acceptable compromise on
the operator keyword? It removes one of the more annoying hurdles that
Danack mentioned and that others have pointed out, but retains much of the
benefits of the keyword that I expressed in my last email.

Jordan


Hello,

I'm not an internals hacker nor someone who can vote, but here is my 
opinion about operator overloading: I don't like it. Nevertheless, if it 
has to be done, I'd like it to be less challenging for PHP newcomers or 
everyday developers.


An operator is not much more than a function shortcut, gmp examples 
prove that point quite well. I don't see why it is necessary to create a 
new syntax. It seems in the discussion that the magic method ship has 
sailed, but I'd much prefer it.


I don't see why a user wouldn't be able to call an operator 
method/function outside of the operator context. It has a signature: 
left operand and right operand are its parameters, and it has a return 
type. The engine internally will just call this function as userland 
code could do.


I think that adding a new syntax for it, and allowing weird function 
names which are the operator symbols will probably create some mind fuck 
in people's mind when reading the code. I like things being simple, and 
I'd love operator overloads to be simple functions, no more no less, not 
"a new thing". The more PHP syntax grows the more complex it is to learn 
and read.


Regarding the naming debate about operator names being different 
depending upon the context, I agree, but I don't care, if operators have 
a name in the engine, I'd prefer methods to carry the same name even if 
it yields a different name in the domain semantics of the object: if you 
are the low level operator function developer, you know what you are 
doing furthermore you can still comment code. If you're the end user, 
you will read the domain API documentation, not the code itself in many 
cases.


If the names are a problem, why not registering those using an attribute 
? If I remember well it was mentioned somewhere in the mail thread, it 
would provide a way to explicitly register any method, with any name, as 
being an operator implementation, sus userland could keep both syntax 
and use the one they wish (i.e. $newNumber = $number->add($otherNumber); 
or $newNumber = $number + $otherNumber. It's not insane to keep this 
possibility open, on the contrary, it'd leverage the fact that operator 
overloading in some context is just a shiny eye candy way of writing 
some domain function shortcut.


That's my opinion and I don't if it worth a penny, but in my mind, an 
operator is a function, and there's no reason that it'd be a different 
thing.


Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: Finishing AVIF support in getimagesize()

[Pierre Joye]

Good evening,

On Wed, Dec 8, 2021, 6:40 PM Christoph M. Becker  wrote:

> On 01.12.2021 at 00:52, Ben Morss via internals wrote:
>
> l
>
> Thanks for your and your colleague's work!  It's highly appreciated.
>
> Anyhow, a respective PR[1] has been submitted now, and I'm in favor of
> bundling libavifinfo.  I'm not too concerned regarding the additional
> size of the PHP binaries which would result by linking it in, but if
> others are, we could still introduce a configuration option (e.g.
> `--with-libavifinfo`).
>
> Thoughts?  Objections to bundling libavifinfo at all?
>
> [1] <https://github.com/php/php-src/pull/7711>
>

On a general principle, I understood that bundling libs should be avoided.

I am not totally sure aviinfo is stable enough to be bundle either way.

The format will  be widely used in a near future so i would rather allow it
if libavinfo js available rather than  bundling it.

best,
Pierre

>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Allowing NULL for some internal functions

[Pierre Joye]

On Thu, Dec 2, 2021, 10:20 PM Sara Golemon  wrote:

I'm not hard against this idea.  The interpretation of null in these
> contexts as being equivalent to empty string isn't unreasonable.  I guess
> the only objection I could have would be an academic one and I can't really
> defend that.  So yeah, sure... why not?
>
> I would say that such applications should consider unifying their own
> types.  $a = $_GET['q'] ?? '';   Is there a place in the application where
> empty string and null would have been distinct? i.e. Is a search for
> nothing different from not searching?
>


I wonder what is the technical benefit from that?

I do feel we are moving to a strict typed language. If that is what is
desired, then let decide it clearly and move forward to rhst direction.

best,
Pierre

>

Re: [PHP-DEV] Fork microsoft/php-sdk-binary-tools to PHP org on GH

[Pierre Joye]

Hi Christoph,

On Wed, Dec 1, 2021, 5:48 PM Christoph M. Becker  wrote:

> Hi all,
>
> since Microsoft won't support PHP 8 and beyond, it appears to be
> reasonable to fork the microsoft/php-sdk-binary-tools[1] to the PHP org
> account on Github.  The PHP-SDK is required to build PHP on Windows[2],
> and at least some adaptions to newer PHP versions need to be done[3],
> and there is a PR for building for arm64[4], which may be rejected by
> Microsoft.
>
> Thoughts?  Objections?
>

yes please.

And get ride of the CLA while being  at it.


best,
Pierre

>

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Pierre Joye]

Hi Nikita,

On Thu, Nov 25, 2021 at 3:47 PM Nikita Popov  wrote:

> Travis is working again.

In the meantime, I asked AWS if it is ok to share GD's graviton box
with php, all good.

If we don't have one, happy to add you there. GH Actions already in
place, only need to set up two accounts (I never did but should be
smooth :).

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Need Update regarding PHP Travis CI Execution

[Pierre Joye]

Hi Nikita,

On Wed, Nov 24, 2021, 6:55 PM Nikita Popov  wrote:

> On Wed, Nov 24, 2021 at 12:42 PM Chandranana Naik <
> chandranana.n...@ibm.com>
> wrote:
>
> >
> > Hi Team,
> >
> > Recently Travis builds have stopped running for PHP.
> > We only see Cirrus and appveyor CI builds,  however travis.yml exists in
> > the github repo.
> >
> > Could you please update if Travis builds will be started again or if
> there
> > are plans to disable Travis CI support ?
> >
>
> Hi,
>
> I've sent a support request to Travis to extend us additional open-source
> credits, so hopefully this will be running again soon.
>
> Generally though, I would recommend you to migrate from Travis CI to GitHub
> Actions. The PHP project itself uses Travis CI for testing non-x86
> platforms only, which are generally not available on other CI providers.


what we did for GD. Also adding arm is simple as the gh ci bot works on arm.

For ppc and other there is a gh bot port typescript and this is the one we
use. Only need to install it instead of gh one, gh website parts remain the
same.

Best,
Pierre

Re: [PHP-DEV] PHP 8 Release Announcement Page

[Pierre]

Le 19/11/2021 à 10:10, Kamil Tekiela a écrit :

I would suggest option number 5. Leave it as it is. Many people are still
not aware that PHP 8 has been released.
If that's not possible, then we should keep the page (opt 3), otherwise we
will be breaking links to it, e.g. on Stack Overflow.
Adding PHP 8.1 alongside would be great, but we already have upgrade pages,
so I'm not sure the effort is worth it.


Hello,

I do not agree, PHP 8 release page was really nice (even for me daily 
reading internals) and I think it could be a nice tradition to keep.


8.1 does bring lots of nice stuff, which deserve a nice presentation.

Regards,

--

Pierre

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Tue, Nov 16, 2021 at 4:11 PM Lynn  wrote:
>
>
>
> On Tue, Nov 16, 2021 at 4:52 AM Pierre Joye  wrote:
>>
>>
>> My vote will change to yes as soon as the change is an opt-in instead of an
>> opt-out for the 8.x lifetime.
>>
>
> What is the point of this change if it's an opt-in? Projects that are still 
> relying on dynamic properties today and "have no time" to fix them now, won't 
> have time in 3 years either. Please let us have nice things today instead of 
> years from now :)

If it is an opt-in (like Larry proposes f.e.), you will have them
today as well.

Best,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

Hi,

On Tue, Nov 16, 2021, 4:40 AM Matthew Brown 
wrote:

> On Fri, 12 Nov 2021 at 08:08, Nikita Popov  wrote:
>
> > Hi internals,
> >
> > I've opened the vote on
> > https://wiki.php.net/rfc/deprecate_dynamic_properties. Voting will close
> > 2021-11-26.
> >
> > Regards,
> > Nikita
> >
>
>
> I encourage people to vote "yes" on this, if you want PHP to be better
>

My vote will change to yes as soon as the change is an opt-in instead of an
opt-out for the 8.x lifetime.

best,
Pierre

>

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Pierre Joye]

On Sun, Nov 14, 2021, 11:42 PM Rowan Tommins 
wrote:

> On 14/11/2021 11:48, Pierre Joye wrote:
> > Also I do see it as a kind of strict mode addition and the depreciation
> as
> > well could be strict mode only.
>
>
> A quick reminder that PHP has no "strict mode". It has a "strict_types"
> declaration, which is probably misnamed, and should be something like
> "scalar_types=error" vs "scalar_types=coerce".
>
> yes, wrong word.
>

-- 
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>