Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:125499
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.10\))
Subject: [PHP-DEV] Zephir, and other tangents
Message-ID: <A247BB36-9FD1-4AAF-AAB8-82DBD9DE3550@newclarity.net>
Date: Tue, 10 Sep 2024 22:57:23 -0400
Cc: PHP internals <internals@lists.php.net>
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
From: mike@newclarity.net (Mike Schinkel)

Hi Rowan,

This message is in reply to https://externals.io/message/125455#125496 =
from the thread "bikeshed: Typed Aliases"

> On Sep 10, 2024, at 5:35 PM, Rowan Tommins [IMSoP] =
<imsop.php@rwec.co.uk> wrote:
> On 10 September 2024 19:32:19 BST, Mike Schinkel <mike@newclarity.net> =
wrote:
>> BTW, why has nobody ever mentioned Zephir on this list (that I am =
aware of?)
>=20
> Zephir is an interesting idea that has never quite fulfilled its aims. =
The Phalcon developers hoped that creating a more PHP-like language =
would allow more people to work on extensions such as their framework, =
but it doesn't seem to have worked out that way.=20
>=20
> The worse problem was that Zephir itself had very few contributors. A =
few years ago, the project came close to shutting down as there was =
nobody left to maintain it; Phalcon was to be rewritten in PHP. =
<https://blog.phalcon.io/post/the-future-of-phalcon> Since then, =
somebody has stepped up, but Phalcon work is still focussed on the PHP =
rewrite, with the intention of a smaller, optional, extension providing =
performance-critical components. =
<https://blog.phalcon.io/post/phalcon-roadmap>

Thank you for the details about Zephir, as I was not fully aware of its =
history. =20

On the surface it looks like a really promising project, it is a shame =
that more people are not interested in seeing it be successful so that =
it could be maintained and improved.

BTW, my rhetorical comment asking why nobody mentions it on the list was =
really an indirect reference to the "Using and Mentioning Third-party =
Packages" thread[1] I have wanted to comment on but have not had the =
time to read the full thread and craft an argument that I hope would be =
compelling to many people.

> Meanwhile, PHP 7 and 8 have massively increased both the performance =
and the capability of code written in PHP, and even FFI to bridge to =
existing native binaries (although I gather there's a lot that could be =
improved to make that more useful).
> <snip>
> ...except to say that I think we should be aiming to reduce the =
difference between what can be done in extensions and what in PHP code, =
rather than planning any new such differences.

True, but let us split this into two discussions. One discussion you =
made here which is "make PHP better rather than make ways to extend PHP =
externally."=20

The 2nd is the discussion I was having which was more constrained, i.e. =
"In the case of operator overloading that I argue we should not offer in =
userland I was exploring the idea of adding internal features that allow =
extensions to be developed to address those use-cases, and especially =
for extensions that would be included in core, not necessarily for =
optional extensions." =20

Before we address the broad question let us address the narrow one I was =
focused on.=20

First, do you think we should add general operator overloading as in =
C++, Python, C#, Swift, Ruby, Kotlin and Dart, or do you agree that =
adding it would be opening Pandora's box?  If you think we should add =
operator overloading then we can agree to disagree.

If you agree we should not add then do you agree that we could add =
operator overloading for specific classes in core, such as if we added a =
Money or Currency class? Ignore whether you think we should add a Money =
or Currency class =E2=80=94 assume we should =E2=80=94 and just answer =
if you think we should allow operator overloading for classes added to =
core where we can standardize the operator's meanings across all uses of =
PHP?

If you've gotten this far and we are still in agreement then I was =
looking for a way to make it easier to add operator overloading for =
classes to be added to core. So your comment "to reduce the difference =
between what can be done in extensions and what in PHP code, rather than =
planning any new such differences" was really presenting my argument as =
apples when I was instead discussing oranges. Though I can certainly =
understand if that was not previously clear to you, hopefully it is now.

(Alternately, for operator overloading, do you see any way in which we =
could constrain userland operator overloads such that we would not end =
up many different competing meanings of plus, minus, times, divide, =
equals, not equals, etc. for similar types of classes? I certainly =
cannot envision how we could constrain it in a useful way.)

-----------

With that covered I'll respond to your more general argument which I =
characterized as you advocating to  "Make PHP better rather than make =
ways to extend PHP externally."=20

Generally, I agree. Where it is possible =E2=80=94 and not harmful =E2=80=94=
 to do so, it would be better to make PHP better than to just find ways =
to extend PHP in other ways. =20

But let us be realistic and honest with each other. PHP has many =
strengths but it also has weaknesses that it will never be able to =
address without changing the essential nature of PHP and without huge BC =
breakage.=20

And for those things were PHP is not great =E2=80=94 or where we see =
foot-guns so we explicitly do not want to add to userland =E2=80=94 it =
would make sense to enable PHP to be extended through other means.  And =
*especially* in ways that do not require being in control of the server =
PHP is running on given how ubiquitous managed hosting has become for =
many who run PHP apps.

I discussed with you privately several years ago how I thought =
supporting WebAssembly[2][3] would be huge boon to PHP, and at the time =
I seem to remember you barely knew about it and were thus dismissive. =
IMO then and now, supporting WASM in PHP Core would make certain things =
possible that would only otherwise be possible in extensions written in =
C or I guess via the FFI in other languages, but make it possible =
without having control of the server PHP is running on, and in any =
language that supports WASM.

What things is PHP not great at?  Real-time code, not using lots of =
memory when processing huge data structures, C-levels of performance, =
and probably a few other things. =20

The thing is, if we allow people to extend PHP in other ways and PHP is =
just as good as extending in those other ways, people will almost =
universally default to using PHP. So I don't see danger in harming PHP =
by enabling PHP to be extended in other languages for those things PHP =
is not good at.

> The overall trend is to have only what's absolutely necessary in an =
extension.

Not sure what you mean here. When I say "extension in core" I mean an =
extension that ships with core. If that is a trend to move away from for =
some reason then substitute "in core" for every place I wrote "an =
extension in core."  Effectively that point is red herring for the point =
I was trying to make.

> and there have even been suggestions that some built-in functions =
would be better off implemented in PHP itself, if the right low-level =
features were included.

Now implementing PHP in PHP =E2=80=94 assuming I understand what you =
mean =E2=80=94 is something I have been wanting and occasionally =
mentioning for years.=20

Specifically I think it would make great sense to have some of the =
standard library that ships in core to be written in PHP which would =
open up the ability for more people to contribute to PHP core taking =
some burden off the maintainers of core who program in C, and would mean =
that every improvement in the C part of PHP would make all the PHP parts =
of PHP better.  Is that what you meant?  =20

If yes, want to collaborate on an RFC?  I know at least a few others who =
would jump at the change to pursue this.

-Mike

[1] https://externals.io/message/125279
[2] https://en.wikipedia.org/wiki/WebAssembly
[3] https://webassembly.org/=