[PHP-DEV] PHP 7.4.27 Released!

[Derick Rethans]

The PHP development team announces the immediate availability of PHP
7.4.27. This is a bug fix release, and the LAST active support release
of the PHP 7.4 series. From now on, only security releases will be
created for the PHP 7.4 branch.

All PHP 7.4 users are encouraged to upgrade to this version.

For source downloads of PHP 7.4.27 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site. The list of
changes is recorded in the ChangeLog.

A migration guide is available in the PHP Manual. Please consult it for the
detailed list of new features and backward incompatible changes.

Release Announcement: 
Downloads:
Windows downloads:
Changelog:
Migration guide:  

Many thanks to all the contributors and supporters!

Derick Rethans

P.S. Below is the verification information for the downloads, which is
also available on
.


php-7.4.27.tar.gz
SHA256 hash: 564fd5bc9850370db0cb4058d9087f2f40177fa4921ce698a375416db9ab43ca
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmG41aYACgkQkQ3rRvU+
oxLweQ/+I+lcbdOIbLFSDUmWlZ85Wz8v8YZ02TcXqdJNIWcDU5DkFdoWSVkcR1pB
8u4BHjhMQtj+f6K1Z0X8hUfSJ7P5sDQCoI1Vuel6sosO5WqbIuhJOiOinNMOdXoX
5Qz6F0j+MqgN7NfjAko1WGr97H4rSnnu+HPWR2vqs2PyVabReX5q4QFGTWKVo58b
NjSEg5dhjI4Wi+5l1vmEMMItdY3pcVOusHiW19j2neIMAGUvG70Fe8E7x+iR6MqF
oIZ8mLPQFpiKlKRAIn6fa2Z9qm8vOoyI7rM9Uxa4z52AzcQFnKgBp9OkCHEpN3vJ
xFAlTodmRKi/MzsuxXb00IEvx2092prvWRQPPHt1CMobWdMIMi+DYualiUGTnBPJ
iYR/tqBOxLyr2UENTK3N3XclhRePR+lzZuit+K8JLrWn0w0hgA8BHHQxkhSTfe/W
7Vac9pxC5ltuPrs/joAPQYaT7ptx1OSW20+B4tPRmNiTpXrAgRbrVfNMWJA8IttT
0LrXLLu/vugoULETGVt9FjBpEMyhtD0ry96dbDIzyXbFccl6oPufVn+kxAPdg71u
fVMDCKpHJPn9VpRqeSynRnjm+RezpOdF+auZmVtqvajcgQZI01WF/VgT2BtqewRn
BDQUnMaNcswGtbGSCmsFk67FcbtolF7qyhElS681E9NMPnwJLMw=
=Nx2P
-END PGP SIGNATURE-

php-7.4.27.tar.bz2
SHA256 hash: 184aaef313fbf28c9987f6aa07b655cd1b0eae9e7e17061775a3e7d880185563
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmG41aoACgkQkQ3rRvU+
oxKu4RAAgZlA1eHX5ovWtV49DURhPkVq61sMJGxKkWxDnAVvmxBmNnfavCPhv95j
Kzxv1ohQXXoNjXFPb4sRJiBOd4/+o8V6j30FDamH7PKOpiEHUlMb0DgLQIjEcAec
ybCy/g3DPj0gadVWMyZLEGd1Hhm5XOHjQkI5YoTM0roAcLV44gr4iswUiu6A19Xi
n/29fCqwVf6CtWSyz1j75acTnbj0JKEFxRlLRpSFGnb5IOa6NUynba1OG5hkOK5E
2Nyc+yvcBQfoMdn/69MOOzNg6xwwL0BmpenGhvFLoNrP5t2+qsdwGj0b436cnJmK
3FcGKaOZ+pV9i1aTU6pyz7mjtNyVHkqfi8ffSfZPxmMTpIAo3oYPnuFOgiYll1oG
w6TzZmPVMNqXupNk83tzGS8zUjlrQFpsRX1mfs6EiZmvuPyeUNWZ+bHc2RGQQjH/
6H7TuDaU8UuOXUD9Quo389m4BdJq2WZULpDgXGZDrMludHSCzKZybsCWiCEm0ls5
RqF2pmFpL7IGw1UhDWYImwkmrbw5bkoZJ0nxOYwD3DqLyHs2gbTYypjp8zXEwWso
zdI1tkttyIKvXAMd+wiBu8qqhG3gNtUBotfQZH5+C5g9Xt+2GU/oFalZddWMXZuh
2yhpBDbYs8BiHCPGm5buhMacs1D5p+elVc8XmnYvKK92omwpJJI=
=jNkR
-END PGP SIGNATURE-

php-7.4.27.tar.xz
SHA256 hash: 3f8b937310f155822752229c2c2feb8cc2621e25a728e7b94d0d74c128c43d0c
PGP signature:
-BEGIN PGP SIGNATURE-

iQIzBAABCgAdFiEEWlKIB4H3VWCL+BX8kQ3rRvU+oxIFAmG41aoACgkQkQ3rRvU+
oxKl+hAA43XgyR/ncx/nnIE+Wa9+inDEzYDNAwaf+g9XGAVLQl0KIDsJvI/pMRju
hY/b8NjWmTz2Arwd8Jhie8B9InyqmSnaej7uUh+krQ8Yp9+tW3UgQz0vIUEZIfy0
GYXYkJpB4jaJmh5V/usxyL/dsTwAJUszaiWAB3AVyVenTRyXrr6NhoE8eP6RJVp5
YTpR0U3x1u/W9JyiCC2eP53R992ltRUnXfb7YuOx9to2+wTDuPBjlrbyNjtY9n63
uuJDuLeyoQ+sfexQ5EO/f4oLGh1P99zMuvfBm0UGdOcffbRSGjr/rkOuIfkmd8jC
uFbf35aoomV5NdTa1EbdhYVgrh/NhYxQc7TIe4rTBapTLbRHQ1hbdkAtW97K1E7j
wTEYmZYU88k1WwvDnvt7w/p6gz6w4JEjY6X+LHiSQjwjsagkm4rHzqd1jX+VU+JH
U62lcPoSJc3yqg1jx1j0nU47tnUBfGeSyQFBil+Q/4auksz2ycCHtteVWXgpXprn
BjyH2T0V9UDQD7sbSjJyDOit3gJkzfH8KtqYnfwHyia6wtpfM4uh6pTXdxgv1ofn
VAfjmDVUDriFb9mAe8cfutoakxs7WzrLpfzys1ENBGpy5TbIHBUFhJW2IBXEhuoX
BL3gUPp1cX1tF0aF1Q+rJCV2Hu08hUD9FA2lBZdRm63TgXqmZuw=
=NUDl
-END PGP SIGNATURE-


-- 
PHP 7.4 Release Manager
Host of PHP Internals News: https://phpinternals.news
Like Xdebug? Consider supporting me: https://xdebug.org/support
https://derickrethans.nl | https://xdebug.org | https://dram.io
twitter: @derickr and @xdebug

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

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

[Jordan LeDoux]

On Fri, Dec 17, 2021 at 12:26 PM Matt Fonda  wrote:

>
> Thanks for the info. I share Stas's unease with having many different
> places we must look in order to understand what $foo * $bar actually
> executes. I'm also uneasy with the requirement of union typing in order for
> an operator to support multiple types. This will lead to implementations
> which are essentially many methods packed into one: one "method" for each
> type in the union, and potentially one "method" for each LHS vs. RHS. When
> combined, these two issues will make readability difficult. It will be
> difficult to know what $foo * $bar actually executes, and once we find it,
> the implementation may be messy.
>
> I agree that returning a union is a recipe for a problem, but the fact
> that the input parameter must be a union can imply that the return value
> must also be a union. For example, Num * Num may return Num, but Num *
> Vector3 may return Vector3, or Vector3 * Vector3 may represent dot product
> and return Num. But let's not get hung up on specific scenarios; it's a
> problem that exists in the general sense, and I believe that if PHP is to
> offer operator overloading, it should do so in a way that is type safe and
> unambiguous.
>
> Method overloading could address both issues (LHS always "owns" the
> implementation, and has a separate implementation for each type allowed on
> the RHS). But I see this as a non-starter because it would not allow scalar
> types on the LHS.
>
> It's difficult to think of a solution that addresses both of these issues
> without introducing more. One could imagine something like the following:
>
> register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
> register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
> register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
> But this just brings a new set of problems, including visibility issues
> (i.e. can't use private fields in the implementation), and the fact that
> this requires executing a function at runtime rather than being defined at
> compile time.
>
> I don't have any ideas that address all of these issues, but I do think
> they deserve further thought.
>

With respect, these are not things that were overlooked. Method overloads
is something that I understand to be a complete non-starter within PHP. I
do not want to speak for other people, but I have been told multiple times
by multiple people that this is a feature which there is significant
resistance to, to the point of being something which should be avoided.
Certainly, it is a separate feature from operator overloading, and
shouldn't be included as part of this RFC.

As you noted, all of the alternatives have multiple *other* issues. I
considered many different ways to implement this, and I decided that this
particular way of doing it presented the fewest problems. The reason I made
that decision was that problems such as visibility issues would affect
nearly every implementation. But the issue of non-sibling type resolution
is something which would only affect a small subset of very complicated
programs in general. So I chose to confine the issues to the more complex
implementations, because these are likely also the ones where the developer
is more experienced or has more resources to solve the issues presented.

In general, unioning types should be seen as a "code smell" with this
feature in my personal opinion. If you start to see 4, 5, 6 different types
in your parameters, it should be a signal that you want to re-examine how
you are implementing them. I think it works well for this purpose, as many
developers already try to refactor code which has very complicated type
unions. Given that method overloads were off the table, and that the only
realistic way to provide for visibility concerns was to place the overloads
on classes, I see the requirement of union typing the operators as a guard
rail to help developers avoid implementations which are prone to error or
make the program excessively complex to understand.

If we created something instead that was a global register of type
combinations, such as those suggested by Mel, the implementations would
likely be all in one place (some kind of bootstrap or header file), but now
would be completely separated from the actual implementations.

I *did* consider all these issues quite extensively. I *think* that the
solution I'm presenting creates the smallest amount of issues for the
smallest set of users. In practice, the two most common usages for this
feature (in my estimation) are likely to be userland scalar object
implementations, and currency objects. Both of these are very
self-contained, and unlikely to want to interact with external objects. The
main applications that would be interested in doing that are complex
mathematical libraries (the kind of application that would fit your example
of Vector * Num). Such libraries are very likely to make subordinate calls
within the operator overloads, as th

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

[Mel Dafert]

Hello internals,

>register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
>register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
>register_operator(*, function (int $lhs, Foo $rhs): int { ...});
>
>But this just brings a new set of problems, including visibility issues
>(i.e. can't use private fields in the implementation), and the fact that
>this requires executing a function at runtime rather than being defined at
>compile time.

Since this is going deeply into magic land anyways, we could go another step 
further
and make this a builtin/"macro" that does happen at compile-time, but also can
impose additional restrictions on what is
allowed - namely, that the registered function must not be inlined but a static
method on one of the arguments.

For example: (syntax completely imaginary here but slightly inspired by rust):

register_operator!(+, lhs: Bar, rhs: Foo, ret: Bar, Bar::addFooBar);
register_operator!(+, lhs: Bar, rhs: Bar, ret: Bar, Bar::addBar);
register_operator!(+, lhs: int, rhs: Bar, ret: int, Bar::addBarInt);
register_operator!(+, lhs: Foo, rhs: int, ret: Foo, Foo::addFooInt, 
commutative: true);

with

class Bar {
...
public static addFooBar (Bar $bar, Foo $foo): Bar { }
// etc.
}

Advantages:
- Explicitly named methods that can be called/tested separately
- Slightly improved searchability - grepping "register_operator" will show all 
operator
combinations inside a code base
- Cannot implement operators for arbitrary classes that one does not own - the 
method
must be from one of the operands
- Multiple distinct methods per operand/class without full method overloading
- No restrictions around having scalar types only as rhs

If I am not mistaken, the engine should also be able to typecheck the methods
to ensure that the types are correct, and additionally also be able to disallow
overlaps (eg. defining Foo+Bar commutitatively as well as Bar+Foo),
which should throw an error as soon as the second definition is encountered.

Disadvantage: This sounds like a lot of work to implement, and I am not sure
if the checks are even possible the way I'm imagining them (with classes being
loaded on demand, etc.).
Also, this syntax would definitely need work, I just wanted to point out that 
on the
drawing board, many of these design problems are solvable.

Whether they are worth the effort, and whether this is a good idea at all, is 
left
for others to decide.

Regards,
Mel

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

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

[Matt Fonda]

On Fri, Dec 17, 2021 at 10:37 AM Jordan LeDoux 
wrote:

> On Fri, Dec 17, 2021 at 9:43 AM Matt Fonda  wrote:
>
>> Hi Jordan,
>>
>> Thanks for the RFC. I have a couple questions:
>>
>> Suppose I have classes Foo and Bar, and I want to support the following
>> operations:
>>
>> - Foo * Bar (returns Foo)
>> - Bar * Foo (returns Foo)
>>
>> If I understand correctly, there are three possible ways I could
>> implement this:
>>
>> a) Implement the * operator in Foo, accepting a Foo|Bar, and use the
>> OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
>> implement the necessary logic accordingly.
>> b) Implement the * operator in Bar, accepting a Foo|Bar, and use the
>> OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
>> implement the necessary logic accordingly.
>> c) Implement the * operator in Foo, accepting a Bar (handles Foo * Bar
>> side); Implement the * operator in Bar, accepting a Foo (handles Bar * Foo
>> side)
>>
>> Is this understanding correct? If so, which is the preferred approach and
>> why? If not, can you clarify the best way to accomplish this?
>>
>
> You are correct in your understanding. All three of these would accomplish
> what you want, but would have varying levels of maintainability. Which you
> choose would depend on the specifics of the Foo and Bar class. For
> instance, if the Bar class was one that you didn't ever expect to use on
> its own with operators, only in combination with Foo, then it would make
> sense to use option 1. The inverse would be true if Bar was the only one
> you ever expected to use with operators on its own.
>
> The better way, in general, would be for Foo and Bar to extend a common
> class that implements the overload in the *same* way for both. In most
> circumstances, (but not all), if you have two different objects used with
> each other with operators, they should probably share a parent class or be
> instances of the same class. Like I said, this isn't always true, but for
> the majority of use cases I would expect it is.
>
>
>> Next, suppose I also want to support int * Foo (returns int). To do this,
>> I must implement * in Foo, which would look like one of the following
>> (depending on which approach above)
>>
>> public operator *(Foo|int $other, OperandPos $pos): Foo|int { ... }
>> public operator *(Foo|Bar|int $other, OperandPos $pos): Foo|int { ... }
>>
>> Now, suppose I have an operation like `42 * $foo`, which as described
>> above, should return int. It seems it is not possible to enforce this via
>> typing, is that correct? i.e. every time I use this, I am forced to do:
>>
>> $result = 42 * $foo;
>> if (is_int($result)) {
>> // can't just assume it's an int because * returns Foo|int
>> }
>>
>
> In general I would say that returning a union from an operator overload is
> a recipe for problems. I would either always return an int, or always
> return an instance of the calling class. Mostly, this is because any scalar
> can be easily represented with a class as well.
>
> Jordan
>

Hi Jordan,

Thanks for the info. I share Stas's unease with having many different
places we must look in order to understand what $foo * $bar actually
executes. I'm also uneasy with the requirement of union typing in order for
an operator to support multiple types. This will lead to implementations
which are essentially many methods packed into one: one "method" for each
type in the union, and potentially one "method" for each LHS vs. RHS. When
combined, these two issues will make readability difficult. It will be
difficult to know what $foo * $bar actually executes, and once we find it,
the implementation may be messy.

I agree that returning a union is a recipe for a problem, but the fact that
the input parameter must be a union can imply that the return value must
also be a union. For example, Num * Num may return Num, but Num * Vector3
may return Vector3, or Vector3 * Vector3 may represent dot product and
return Num. But let's not get hung up on specific scenarios; it's a problem
that exists in the general sense, and I believe that if PHP is to offer
operator overloading, it should do so in a way that is type safe and
unambiguous.

Method overloading could address both issues (LHS always "owns" the
implementation, and has a separate implementation for each type allowed on
the RHS). But I see this as a non-starter because it would not allow scalar
types on the LHS.

It's difficult to think of a solution that addresses both of these issues
without introducing more. One could imagine something like the following:

register_operator(*, function (Foo $lhs, Bar $rhs): Foo { ...});
register_operator(*, function (Bar $lhs, Foo $rhs): Foo { ...});
register_operator(*, function (int $lhs, Foo $rhs): int { ...});

But this just brings a new set of problems, including visibility issues
(i.e. can't use private fields in the implementation), and the fact that
this requires executing a function at runtime rather than being defined at
comp

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

[Jordan LeDoux]

On Fri, Dec 17, 2021 at 10:36 AM Stanislav Malyshev 
wrote:

> And that's one of the reasons I feel so uneasy with this. When reading
> this code: $foo * $bar - how do I know which of the ways you took and
> where should I look for the code that is responsible for it? When I see
> $foo->times($bar) it's clear who's in charge and where I find the code.
> Terse code is nice but not at the expense of making it write-only.
>

I think that something on php.net that focuses on best practices and things
to watch out for could go a long way towards this. In general, when people
search for information on how to do something, if that information isn't in
the PHP manual, they'll end up getting a random answer from stackoverflow.
I'd definitely be willing to put in some work to help on such documentation.

I very much expect that this feature will result in community developed
standards, such as a PSR.

Jordan

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

[Jordan LeDoux]

On Fri, Dec 17, 2021 at 9:43 AM Matt Fonda  wrote:

> Hi Jordan,
>
> Thanks for the RFC. I have a couple questions:
>
> Suppose I have classes Foo and Bar, and I want to support the following
> operations:
>
> - Foo * Bar (returns Foo)
> - Bar * Foo (returns Foo)
>
> If I understand correctly, there are three possible ways I could implement
> this:
>
> a) Implement the * operator in Foo, accepting a Foo|Bar, and use the
> OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
> implement the necessary logic accordingly.
> b) Implement the * operator in Bar, accepting a Foo|Bar, and use the
> OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
> implement the necessary logic accordingly.
> c) Implement the * operator in Foo, accepting a Bar (handles Foo * Bar
> side); Implement the * operator in Bar, accepting a Foo (handles Bar * Foo
> side)
>
> Is this understanding correct? If so, which is the preferred approach and
> why? If not, can you clarify the best way to accomplish this?
>

You are correct in your understanding. All three of these would accomplish
what you want, but would have varying levels of maintainability. Which you
choose would depend on the specifics of the Foo and Bar class. For
instance, if the Bar class was one that you didn't ever expect to use on
its own with operators, only in combination with Foo, then it would make
sense to use option 1. The inverse would be true if Bar was the only one
you ever expected to use with operators on its own.

The better way, in general, would be for Foo and Bar to extend a common
class that implements the overload in the *same* way for both. In most
circumstances, (but not all), if you have two different objects used with
each other with operators, they should probably share a parent class or be
instances of the same class. Like I said, this isn't always true, but for
the majority of use cases I would expect it is.


> Next, suppose I also want to support int * Foo (returns int). To do this,
> I must implement * in Foo, which would look like one of the following
> (depending on which approach above)
>
> public operator *(Foo|int $other, OperandPos $pos): Foo|int { ... }
> public operator *(Foo|Bar|int $other, OperandPos $pos): Foo|int { ... }
>
> Now, suppose I have an operation like `42 * $foo`, which as described
> above, should return int. It seems it is not possible to enforce this via
> typing, is that correct? i.e. every time I use this, I am forced to do:
>
> $result = 42 * $foo;
> if (is_int($result)) {
> // can't just assume it's an int because * returns Foo|int
> }
>

In general I would say that returning a union from an operator overload is
a recipe for problems. I would either always return an int, or always
return an instance of the calling class. Mostly, this is because any scalar
can be easily represented with a class as well.

Jordan

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

[Stanislav Malyshev]

Hi!

On 12/17/21 9:43 AM, Matt Fonda wrote:

Hi Jordan,

Thanks for the RFC. I have a couple questions:

Suppose I have classes Foo and Bar, and I want to support the following
operations:

- Foo * Bar (returns Foo)
- Bar * Foo (returns Foo)

If I understand correctly, there are three possible ways I could implement
this:


And that's one of the reasons I feel so uneasy with this. When reading 
this code: $foo * $bar - how do I know which of the ways you took and 
where should I look for the code that is responsible for it? When I see 
$foo->times($bar) it's clear who's in charge and where I find the code. 
Terse code is nice but not at the expense of making it write-only.


--
Stas Malyshev
smalys...@gmail.com

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

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

[Matt Fonda]

Hi Jordan,

Thanks for the RFC. I have a couple questions:

Suppose I have classes Foo and Bar, and I want to support the following
operations:

- Foo * Bar (returns Foo)
- Bar * Foo (returns Foo)

If I understand correctly, there are three possible ways I could implement
this:

a) Implement the * operator in Foo, accepting a Foo|Bar, and use the
OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
implement the necessary logic accordingly.
b) Implement the * operator in Bar, accepting a Foo|Bar, and use the
OperandPosition to determine if I am doing Foo * Bar or Bar * Foo and
implement the necessary logic accordingly.
c) Implement the * operator in Foo, accepting a Bar (handles Foo * Bar
side); Implement the * operator in Bar, accepting a Foo (handles Bar * Foo
side)

Is this understanding correct? If so, which is the preferred approach and
why? If not, can you clarify the best way to accomplish this?

Next, suppose I also want to support int * Foo (returns int). To do this, I
must implement * in Foo, which would look like one of the following
(depending on which approach above)

public operator *(Foo|int $other, OperandPos $pos): Foo|int { ... }
public operator *(Foo|Bar|int $other, OperandPos $pos): Foo|int { ... }

Now, suppose I have an operation like `42 * $foo`, which as described
above, should return int. It seems it is not possible to enforce this via
typing, is that correct? i.e. every time I use this, I am forced to do:

$result = 42 * $foo;
if (is_int($result)) {
// can't just assume it's an int because * returns Foo|int
}

Thanks,
--Matt

[PHP-DEV] PHP 8.1.1 Released

[Patrick ALLAERT]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

The PHP development team announces the immediate availability of PHP
8.1.1. This is a bugfix release.

All PHP 8.1 users are encouraged to upgrade to this version.

For source downloads of PHP 8.1.1 please visit our downloads page.
Windows binaries can be found on the PHP for Windows site.
The list of changes is recorded in the ChangeLog.

Release Announcement: https://php.net/releases/8_1_1
Downloads: https://php.net/downloads
Windows downloads: https://windows.php.net/download#php-8.1
Changelog: https://php.net/ChangeLog-8#8.1.1
Release Manifest:
https://gist.github.com/patrickallaert/fb30c51115caadf4b7eb45499ed3d351

Many thanks to all the contributors and supporters!

Patrick Allaert, Ben Ramsey & Joe Watkins

php-8.1.1.tar.bz2
SHA256 hash:
8f8bc9cad6cd124edc111f7db0a109745e2f638770a101b3c22a2953f7a9b40e
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmG5TK8ACgkQGZ+d/vb/
uv2vuhAAnXP4WyDeds27/KBTR0qP+LCxdOx3ajJgXpyhEgf3b6G7jQA0fhu3XAA5
bm4xvynsfPmYr9RlnS60rmpUK5P3bAdNCCaK9qu3f5C8WF7NWXetl2kbzZr5aZVf
/iL9iduVvKQ0rvEOhFPB/AuxeBVasTLR4A9A0YjNJEzDiWxIL4CfLNaiLguDT0Ia
zhX1EDahF/chenmTJwrwtIFoegW7S9ztYjFJBV3rjl/nknutRBaHQX+bgiKJRd5w
63bsm/W/lxcOHORmK7w2bdUZegb9Htcwt4SRCG1/bEVfX47BsmKmiXtJUzGcNfqR
fUYMihqsMXX95+ht/LQkTIJFlRprzZEO6Cccl0E9hiZ818gl5ehAbT4l+cdcsTxM
xrQlcjR27cK+pK5DCgToZJICmWi1SZI8OYCzB/AijaS/sfCwdl55Yg7jvcyCzv7J
UjnfUKi9WN6is89B6P0VpMlggAfE6L/NXVauN6LNklRW2Y3VT6i6OKAGCONUYPEQ
s7ZE+hkKW4sNhsQbkaLS7IwzHKpS6aIUSd1MS6iGGeHCHZdobaUW7wMVmNqXMErN
9Y/QDPpWQ5cgHRwS6HfgHK4Ac1IzUSOwNf8YnuH9WgXV9ZiMUnGA1MMHDwB/4nmL
/54NbybIT0LluySsG/EloQJm4TshhpWP37IVpU5fTeKUBclS/2Y=
=+0UC
- -END PGP SIGNATURE-

php-8.1.1.tar.gz
SHA256 hash:
4e4cf3f843a5111f6c55cd21de8f26834ea3cd4a5be77c88357cbcec4a2d671d
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmG5TLAACgkQGZ+d/vb/
uv13YQ/+KaUeDvD7dSrF+8KJSBjr8W5Nww11emvO15XGY3MPchpSZiEp7sPRMf6l
e39AFe8OkcdKeTrbXS0vczJR0NC51DJMoOZahVLj8/QiupHapS9InXB8voSjZGT5
IS3umyX82BXq4VfNPUrpKU3IvbgNpruC+l+BacWk9Q/XwnP17lbRRofyh4w7bbgw
ruEbNIEojucpGbb71cwKMk6PBw6rMtID8xBjoyKIHl8ZWmhLTM2cKQ90jdwZdyIt
uIwwayLDmxZ0d2QzzJ5S2SgjINXY75KixFnroEaB7Go5b0DaWl3+jFi2mpleqOpb
mKCY6TLIgc2w1fEJcjyyaNvVmvj3bOpPWN0bBfitbkGB4RqwzFyWstJ+xG47X29+
fX0GJsfTPjJ234Ejia0JSxutRWVuNgt32r046m7lVjX857rlisEC5XPYhitGMDM3
1BspuOpV1tMKzB3rDxzo8ex6XXest1JktZlEoTdeDrf0qpZuINhpYiJoO7ydX+vw
OKgHQS2e2TZWFfrg64ywEJnEnoJcmmkY+yVdQ7WDjyLjDmpYGxxdIqlx0Ht/FAGk
i84gubjOsLSsNuFJLJ3LfQTPb9yf6yiKhVXBACzpEcJoiIFSdN2Cp2/hvRANGS48
Jgfq4DfOlJ5N5dnUIwOg6ej51U59fNs6WR6/LI0JfjH549n1zN0=
=6tTC
- -END PGP SIGNATURE-

php-8.1.1.tar.xz
SHA256 hash:
33c09d76d0a8bbb5dd930d9dd32e6bfd44e9efcf867563759eb5492c3aff8856
PGP signature:
- -BEGIN PGP SIGNATURE-

iQIzBAABCAAdFiEE8faSI4+8FmblpczUGZ+d/vb/uv0FAmG5TLAACgkQGZ+d/vb/
uv0MWRAAvExd3AEpYYO4s3NExVCEO+QXZWYXPFhLcBgQ60OMKgE0EfRiKsoonjaB
RFB1wKvZ6WCyyzaPtVkrcRJUUxO1Tn1dYOd0sd4N2yUhDqzEXorDmwbheSXIjaNd
eoR/YwI5HOxR+ap1HZHe+iAwadKYveZVV5xy5jJk3/UjY7TH5J9g19SMVmn1C2JN
A2QQjgaJLy4bj2UQ51noBJkt6FfDDWgU+dGvMxV9AO2lcm0MO+4UZ3rQk/5io1kL
ee3JnP6OUMCfQc3g36LO9JKIT7Xc7PaPoZevMKbimzhfrgIvKH9hGMAbY35zz8Z2
8TjaABEK7psQmn7hCqEtFuUzYjAbIju4Hu8r1Bozjmgqf+EG//lqyld9Z2oY806m
Vw6XdRWriKdM2sjHFUXXzSC2NuFNUN46k/z58037rkhuyygB4UCy8Sez7zYz48xf
7PMvg83tEHZ0ElyKI3kVKWUSQyKbpOZRQhf+M5E46u3ISFisT7LyEz9jZjKbD1eB
z7zAfSbopYnebL8SFsq6J2g71DUUmJgo0kBi/5ikWTXvGK0VWDagaZ7b/haQscJx
pVuVC1p66W/iTTGuQoVL96C5tkoIBIJ41KFiRhRtlgg3Ub7RIlZIUQ2ufqvIvnUI
hrlJz76sj103X0VUTKlZMWo+a1eJO0hhdNVUwa3WvJe9+iM6dow=
=lXCs
- -END PGP SIGNATURE-

- --
- -Patrick
-BEGIN PGP SIGNATURE-
Version: FlowCrypt Email Encryption 8.2.0
Comment: Seamlessly send and receive encrypted email

wsFzBAEBCgAGBQJhvMqNACEJEBmfnf72/7r9FiEE8faSI4+8FmblpczUGZ+d
/vb/uv04zg/9HICgir/JQ1GoeNTNWwuLh+AxE9uetZoNIJhlDFreAzP/WBD4
vTf8sWo1oNYksVK5+5LeGJZDV87DL/ZtsjJzyiNKVzDvCmmyDJ27BGFIBvMh
UUOlMk9J24CswDAsnwj2Q0w60OG0m1WwG/Gxv9aBGO7Zr+bGFPALFhFdgztL
tNkxkAWAo9OAYs7kZy9O5Op8afL768nQnx5mw5bqr/3pHjWYi0OzzxeQOeGa
472xLxxjHQep/7pStWjGyPUwY7Tm4RgL2u/ulcdkN2XKcFnqh6KT6+rukaPL
1DMN8ukXS9gnUBEuVgxz0FgLBClz4QhWEpJYjVYp7NB+VMNMLz4VrGvsZbCE
RYTXVObwFlFfmrpM0NWqSUvGd0SyZGSD5SZdk58ej9IRRTczlBX3eF08KoWK
fX6t8eJvsgi3m0Lb9dNkmrDujlq7QzQd4902aox3Aul1MErf/+CEE/jVPJBn
R49IKW4Aw6swUAcehbNf/MvpHaLZmIdPkgBgMsgcqqd73ANKYtfCKRK1Vv8o
kivHQ/uDixQvZaJY/DB1DX/96NwXPm4/8MdhJ/q8Yl4HY3AA0NpUzH96ckwM
hsRLVXMkwNVMsF4hIyQ5BD5Lkx1MFFLxN2i/3yekqXgRctrEOs6MXU/GYq+U
eUfX4OwybEwwKRbh1my3Tk+7z2/Lwc+VNsE=
=k9q7
-END PGP SIGNATURE-

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

Re: [PHP-DEV] Surveying interest regarding CMake

[Kalle Sommer Nielsen]

Hi

Den fre. 17. dec. 2021 kl. 01.09 skrev Horváth V. :
> 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.


Kalle Sommer Nielsen
ka...@php.net

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

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

This is way too early to decide this. This is a decision to be made 
when we're actually ready to try publishing it for regular 
consumption (not for the people developing it).


Sure. I wasn't expecting concrete answers, just letting people know that
this ought to be considered as well.

It may take us a few months to develop the cmake system, or it may 
take years, but hopefully not so many years that Ubuntu 20.04

becomes irrelevant.


That feels like a bit of an exaggeration to me. With nothing else taking
my time up, I'm confident I can do the initial work in a week or two.
Unless you mean the total transition, dropping the existing solution and
all that.

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

Re: [PHP-DEV] Surveying interest regarding CMake

[Levi Morrison via internals]

On Fri, Dec 17, 2021 at 6:49 AM Horváth V.  wrote:
>
> One thing I forgot to ask is what minimum CMake version should php-src
> support in its build scripts? For reference, please take a look at
> repology.org for the packaging status of CMake across a lot of software
> distributions: https://repology.org/project/cmake/badges

This is way too early to decide this. This is a decision to be made
when we're actually ready to try publishing it for regular consumption
(not for the people developing it).

For the sake of just sticking a number in that place in the cmake file
for now, I recommend 3.16 as this is what is in Ubuntu 20.04. It may
take us a few months to develop the cmake system, or it may take
years, but hopefully not so many years that Ubuntu 20.04 becomes
irrelevant. Better to downgrade in the end if necessary.

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

Re: [PHP-DEV] Surveying interest regarding CMake

[James Titcumb]

On Thu, 16 Dec 2021, 17:53 Horváth V.,  wrote:

>
> I'm writing to you to find out what the reception here is regarding the
> idea of moving the PHP project to build using CMake.
>

I think this would be a great move overall.

Would the CMake build chain be backported? I'm assuming not, which means
extensions who support older PHP versions than the one that introduces
CMake will need to support autoconf for as long as they want to support
those older PHP versions, I think?

That isn't a deal breaker for me, but a guide on adding support for CMake
would definitely be appreciated and helpful for extension maintainers IMO.

But yes, overall great idea!

Thanks
James

Re: [PHP-DEV] Surveying interest regarding CMake

[Horváth V .]

One thing I forgot to ask is what minimum CMake version should php-src
support in its build scripts? For reference, please take a look at
repology.org for the packaging status of CMake across a lot of software
distributions: https://repology.org/project/cmake/badges

Please note that the lower you go, the less convenience you will be
afforded and the more workarounds you will have to implement to have
that convenience.

Personally, I posit that targeting 3.8 would still allow vast majority
of people to depend on nothing but their system package manager, however
I must note that upgrading CMake is trivial and I recommend anyone
wanting to verify that to read Alex Reinking's blog post about this:
https://alexreinking.com/blog/how-to-use-cmake-without-the-agonizing-pain-part-1.html

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