Re: [PHP-DEV] [RFC] Pipe Operator, take 2

[Mike Schinkel]

> On Jun 7, 2021, at 9:39 PM, Larry Garfield  wrote:
> 
> On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
>> 
>>> On Jun 7, 2021, at 3:00 PM, Larry Garfield  wrote:
>>> 
>>> Hi folks. Me again.
>>> 
>>> A year ago, I posted an RFC for a pipe operator, |>, aka function 
>>> concatenation.  At the time, the main thrust of the feedback was "cool, 
>>> like, but we need partial function application first so that the syntax for 
>>> callables isn't so crappy."
>>> 
>>> The PFA RFC is winding down now and is looking quite good, so it's time to 
>>> revisit pipes.
>>> 
>>> https://wiki.php.net/rfc/pipe-operator-v2
>>> 
>>> Nothing radical has changed in the proposal since last year.  I have 
>>> updated it against the latest master.  I also updated the RFC to use more 
>>> examples that assume PFA, as the result is legit much nicer.  i also tested 
>>> it locally with a combined partials-and-pipes branch to make sure they play 
>>> nicely together, and they do.  (Yay!)  Assuming PFA passes I will include 
>>> those tests in the pipes branch before this one goes to a vote.
>> 
>> In general, much nicer with PFA than before.
>> 
>> A few questions though, although #1 is probably best answered by Derick 
>> Rethans:
>> 
>> 1. Will PHP consider a piped sequence a single expression?  More 
>> specifically, will XDEBUG consider it a single expression, or could 
>> XDEBUG be able to set a breakpoint at each pipe assuming they are on 
>> separate lines?  
>> 
>> I ask because if pipes were an indivisible expression from the 
>> standpoint of XDEBUG and breakpoints I would not want to see them 
>> included in PHP. Alternately if included in PHP I would avoid using 
>> them like the plague just like I avoid using fluent interfaces because 
>> of their inability to be breakpointed at each step in XDEBUG.
> 
> $foo |> bar(?) |> baz(?);
> 
> will produce the same AST as
> 
> baz(bar($foo));
> 
> So whatever Xdebug can do with that AST, it should still be able to do.

That is unfortunate.   

Few people write code or would write code like bazoom(baz(bar(foo($x 
because the trailing parenthesis make it far from ergonomic. What you are 
proposing therefore is an ergonomic way to convert a program into a single 
large expression (when taken to the limit.)

Given that your pipe RFC makes practical a style of coding that was previously 
not practical it begs the question of addressing intermediate steps in the AST 
to support breakpoints, which also might require XDEBUG to introspect the 
values on the calling stack.  

Unfortunately I do not know enough about how the internal representations work 
to argue that this be considered a must; hopefully Derick Rethans will comment 
on this.

-Mike

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

[Larry Garfield]

On Mon, Jun 7, 2021, at 8:09 PM, Mike Schinkel wrote:
> 
> > On Jun 7, 2021, at 3:00 PM, Larry Garfield  wrote:
> > 
> > Hi folks. Me again.
> > 
> > A year ago, I posted an RFC for a pipe operator, |>, aka function 
> > concatenation.  At the time, the main thrust of the feedback was "cool, 
> > like, but we need partial function application first so that the syntax for 
> > callables isn't so crappy."
> > 
> > The PFA RFC is winding down now and is looking quite good, so it's time to 
> > revisit pipes.
> > 
> > https://wiki.php.net/rfc/pipe-operator-v2
> > 
> > Nothing radical has changed in the proposal since last year.  I have 
> > updated it against the latest master.  I also updated the RFC to use more 
> > examples that assume PFA, as the result is legit much nicer.  i also tested 
> > it locally with a combined partials-and-pipes branch to make sure they play 
> > nicely together, and they do.  (Yay!)  Assuming PFA passes I will include 
> > those tests in the pipes branch before this one goes to a vote.
> 
> In general, much nicer with PFA than before.
> 
> A few questions though, although #1 is probably best answered by Derick 
> Rethans:
> 
> 1. Will PHP consider a piped sequence a single expression?  More 
> specifically, will XDEBUG consider it a single expression, or could 
> XDEBUG be able to set a breakpoint at each pipe assuming they are on 
> separate lines?  
> 
> I ask because if pipes were an indivisible expression from the 
> standpoint of XDEBUG and breakpoints I would not want to see them 
> included in PHP. Alternately if included in PHP I would avoid using 
> them like the plague just like I avoid using fluent interfaces because 
> of their inability to be breakpointed at each step in XDEBUG.

$foo |> bar(?) |> baz(?);

will produce the same AST as

baz(bar($foo));

So whatever Xdebug can do with that AST, it should still be able to do.

> 2. Besides `throw` will there be a way to short-circuit evaluation 
> mid-way through the pipes without having to write all of the callables 
> to respect said short-circuiting and just return? 
> 
> For example, could returning an instance of an object that implements a 
> `ShortCircuitPipeInterface` allow the pipe to short-circuit, or some 
> other way to short-circuit and then determine after the pipe if it was 
> short-circuited?

What you're describing is effectively monads.  (There's that scary word again.) 
 That is not covered here, although I mention it in the future scope section.  
There's a couple of ways it could be implemented, although you can already do 
so today in user-space with a method instead of a dedicated operator.  The 
caveat is monads essentially have to be either untyped or use generics, so for 
now we're stuck with untyped monads.

Alternatively, you can wrap each callable in another function that wraps the 
short-circuiting behavior around it.  That's essentially "railroad oriented 
programming", a term coined by Scott Wlaschin:

https://fsharpforfunandprofit.com/rop/

In other words, "I want that, but it comes later, via something more robust."

--Larry Garfield

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

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

[Mike Schinkel]

> On Jun 7, 2021, at 3:00 PM, Larry Garfield  wrote:
> 
> Hi folks. Me again.
> 
> A year ago, I posted an RFC for a pipe operator, |>, aka function 
> concatenation.  At the time, the main thrust of the feedback was "cool, like, 
> but we need partial function application first so that the syntax for 
> callables isn't so crappy."
> 
> The PFA RFC is winding down now and is looking quite good, so it's time to 
> revisit pipes.
> 
> https://wiki.php.net/rfc/pipe-operator-v2
> 
> Nothing radical has changed in the proposal since last year.  I have updated 
> it against the latest master.  I also updated the RFC to use more examples 
> that assume PFA, as the result is legit much nicer.  i also tested it locally 
> with a combined partials-and-pipes branch to make sure they play nicely 
> together, and they do.  (Yay!)  Assuming PFA passes I will include those 
> tests in the pipes branch before this one goes to a vote.

In general, much nicer with PFA than before.

A few questions though, although #1 is probably best answered by Derick Rethans:

1. Will PHP consider a piped sequence a single expression?  More specifically, 
will XDEBUG consider it a single expression, or could XDEBUG be able to set a 
breakpoint at each pipe assuming they are on separate lines?  

I ask because if pipes were an indivisible expression from the standpoint of 
XDEBUG and breakpoints I would not want to see them included in PHP. 
Alternately if included in PHP I would avoid using them like the plague just 
like I avoid using fluent interfaces because of their inability to be 
breakpointed at each step in XDEBUG.


2. Besides `throw` will there be a way to short-circuit evaluation mid-way 
through the pipes without having to write all of the callables to respect said 
short-circuiting and just return? 

For example, could returning an instance of an object that implements a 
`ShortCircuitPipeInterface` allow the pipe to short-circuit, or some other way 
to short-circuit and then determine after the pipe if it was short-circuited?

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

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

[Larry Garfield]

On Mon, Jun 7, 2021, at 4:00 PM, Eugene Leonovich wrote:
> On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield 
> wrote:
> 
> > Hi folks. Me again.
> >
> > A year ago, I posted an RFC for a pipe operator, |>, aka function
> > concatenation.  At the time, the main thrust of the feedback was "cool,
> > like, but we need partial function application first so that the syntax for
> > callables isn't so crappy."
> >
> > The PFA RFC is winding down now and is looking quite good, so it's time to
> > revisit pipes.
> >
> > https://wiki.php.net/rfc/pipe-operator-v2
> >
> > Nothing radical has changed in the proposal since last year.  I have
> > updated it against the latest master.  I also updated the RFC to use more
> > examples that assume PFA, as the result is legit much nicer.  i also tested
> > it locally with a combined partials-and-pipes branch to make sure they play
> > nicely together, and they do.  (Yay!)  Assuming PFA passes I will include
> > those tests in the pipes branch before this one goes to a vote.
> >
> >
> FTR, there are several typos in the "Hello World" examples (*strto*t*upper,
> htmlent*i*ties*). Also, these examples will not work as written because
> explode() expects two arguments and will fail if you pass only one:
> https://3v4l.org/tLO0s. I wonder what the correct version of the pipe
> example (the one that uses strings as callbacks) would look like, given
> that you have to pass two arguments for explode()?

Hm.  You're right.  It used to, but it's been a very long time since explode() 
allowed an empty split, apparently.  I updated the example to use str_split, 
which is what I'd intended to do in this case.  Thanks.

If you wanted to explode with a separator in a non-PFA pipes world, you'd need 
to wrap it in an arrow function.  (Hence why a PFA-world pipe is all around 
better.)

--Larry Garfield

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

Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Christoph M. Becker]

On 07.06.2021 at 13:32, Anatol Belski wrote:

> Removing the centralized PECL builder and dependency manager would most 
> likely lead to a huge regression in the support and manageability. Right now 
> there's one place pecl.php.net to go for the non core extension builds and 
> any dependencies are guaranteed to be non conflicting. If this gets 
> decentralized, the effort is moved to the extension maintainers which will 
> most likely mean the chaos in where to get a DLL, DLL hell issues, absent DLL 
> because the configuration is hard. This will steadily lead to the situation 
> that was there before.
>
> IMO even keeping the basic version of the centralized approach even having a 
> sporadic chance to fix issues is a far better way to go than dropping the 
> existing achievements. Also in the long run, other approaches like moving to 
> vcpkg for deps, checking on other things like cmake and pickle might be a 
> good way, if there's  a community interest. More volunteers on the community 
> side would be great in this sense, too.

Good points, thank you for bringing them up!  I have to fully agree that
we should not drop the central point of distribution (i.e.
windows.php.net).  I don't think, however, that we can stick with the
current PECL build system for long.  Maybe the biggest issue is that
extension maintainers may see automatic DLL builds as a given, or at
least may not be able to fix things, because only few have access to the
build machine.  And even if that was not an issue, not many more would
know where to look at.  In other words, the bus factor is very low, and
it may happen at some point in time, that no new DLLs would be built for
*any* extension.

This is why I still think it would be good to shift some of the burden
of maintaining Windows builds to extension maintainers is a good thing.
 It is not about making their job harder, but rather about preventing
serious issues, and also to correct expectations; extension maintainers
might well assume that their extension is supported on common Linux
distros, but they shouldn't *assume* it is supported on Windows as well
(let alone that the dependency libraries have fixes for all known
relevant security issues).

Even if extensions are developed solely on Linux (and most are, as far
as I know), they should have some Windows CI (at least doing the actual
builds; better to run the test suite as well, of course), and that
shouldn't be a real problem – there are several CI providers which are
free for OSS projects.  We should do our best to provide them with
appropriate tools, so Windows CI integration can be set up as easily as
for Linux phpize builds.  That would not solve the issues regarding
dependencies, but appears to be a reasonable first step in the right
direction.

Thanks,
Christoph

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

Re: [PHP-DEV] [RFC] Pipe Operator, take 2

[Eugene Leonovich]

On Mon, Jun 7, 2021 at 9:03 PM Larry Garfield 
wrote:

> Hi folks. Me again.
>
> A year ago, I posted an RFC for a pipe operator, |>, aka function
> concatenation.  At the time, the main thrust of the feedback was "cool,
> like, but we need partial function application first so that the syntax for
> callables isn't so crappy."
>
> The PFA RFC is winding down now and is looking quite good, so it's time to
> revisit pipes.
>
> https://wiki.php.net/rfc/pipe-operator-v2
>
> Nothing radical has changed in the proposal since last year.  I have
> updated it against the latest master.  I also updated the RFC to use more
> examples that assume PFA, as the result is legit much nicer.  i also tested
> it locally with a combined partials-and-pipes branch to make sure they play
> nicely together, and they do.  (Yay!)  Assuming PFA passes I will include
> those tests in the pipes branch before this one goes to a vote.
>
>
FTR, there are several typos in the "Hello World" examples (*strto*t*upper,
htmlent*i*ties*). Also, these examples will not work as written because
explode() expects two arguments and will fail if you pass only one:
https://3v4l.org/tLO0s. I wonder what the correct version of the pipe
example (the one that uses strings as callbacks) would look like, given
that you have to pass two arguments for explode()?

-- 
Thank you and best regards,
Eugene Leonovich

Re: [PHP-DEV] [RFC] Partial Function Application, take 2

[Björn Larsson]

Den 2021-06-02 kl. 22:16, skrev Mike Schinkel:

On Jun 2, 2021, at 1:45 PM, Larry Garfield  wrote:

Hi folks.  After much off-list discussion, iteration, and consideration, we 
have a new draft of PFA ready for review.

The URL is the same:

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


Really excellent work, all!


It's a bit long because we wanted to be as precise as possible.  However, in 
short:

* Partial application creates a closure object you can use like any other.
* A ? indicates "exactly one required parameter here"
* A ... indicates "zero or more parameters here"


My only comment/request/suggestion is to consider Mark Randall's suggestion to 
use `...?` instead, for the reasons he mentioned in his email to the list:

https://externals.io/message/114157#114666 


Plus Levi Morrison seemed to approve:

https://externals.io/message/114157#114667 


-Mike



I second this opinion. So is the "...?" syntax something that will
be considered?

r//Björn Larsson

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

[PHP-DEV] Re: [RFC] Pipe Operator, take 2

[Björn Larsson]

Den 2021-06-07 kl. 21:00, skrev Larry Garfield:

Hi folks. Me again.

A year ago, I posted an RFC for a pipe operator, |>, aka function concatenation.  At the 
time, the main thrust of the feedback was "cool, like, but we need partial function 
application first so that the syntax for callables isn't so crappy."

The PFA RFC is winding down now and is looking quite good, so it's time to 
revisit pipes.

https://wiki.php.net/rfc/pipe-operator-v2

Nothing radical has changed in the proposal since last year.  I have updated it 
against the latest master.  I also updated the RFC to use more examples that 
assume PFA, as the result is legit much nicer.  i also tested it locally with a 
combined partials-and-pipes branch to make sure they play nicely together, and 
they do.  (Yay!)  Assuming PFA passes I will include those tests in the pipes 
branch before this one goes to a vote.



Thanks! I have been waiting for this :)

r//Björn Larsson

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

[PHP-DEV] [RFC] Pipe Operator, take 2

[Larry Garfield]

Hi folks. Me again.

A year ago, I posted an RFC for a pipe operator, |>, aka function 
concatenation.  At the time, the main thrust of the feedback was "cool, like, 
but we need partial function application first so that the syntax for callables 
isn't so crappy."

The PFA RFC is winding down now and is looking quite good, so it's time to 
revisit pipes.

https://wiki.php.net/rfc/pipe-operator-v2

Nothing radical has changed in the proposal since last year.  I have updated it 
against the latest master.  I also updated the RFC to use more examples that 
assume PFA, as the result is legit much nicer.  i also tested it locally with a 
combined partials-and-pipes branch to make sure they play nicely together, and 
they do.  (Yay!)  Assuming PFA passes I will include those tests in the pipes 
branch before this one goes to a vote.

-- 
  Larry Garfield
  la...@garfieldtech.com

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

Re: [PHP-DEV] [RFC] Readonly properties

[Larry Garfield]

On Mon, Jun 7, 2021, at 4:06 AM, Nikita Popov wrote:
> On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield 
> wrote:

> > Thank you for the detailed analysis in the rationale section.  I am,
> > however, still skeptical of this approach, for a couple of reasons.
> >
> > 1. This does appear to address the "leakage" problem I noted in my earlier
> > analysis around the start of the year, when considering the writeonce
> > proposal[1][2].  That's great to see.
> >
> > 2. It doesn't address the larger question of cloning, however.  The answer
> > for now seems "maybe we'll get clone-with at some point", which would be a
> > way around it, but there is no active RFC for that right now.  I'm
> > obviously very in favor of RFCs that complement each other to give more
> > than the sum of their parts, but those RFCs need to be at least on the
> > horizon to actually come together.  Right now that looks like it won't
> > happen this cycle.  Absent clone-with, readonly would be effectively
> > unusable in any evolvable object of any non-trivial complexity.
> 
> 
> Compared to the general area of applicability of readonly properties, the
> cases that require clone-with are rare. It's the intersection of
> "not-really-immutable objects using wither evolution" and "has so many
> properties that passing them to the constructor is infeasible". While this
> intersection does include a couple of prominent examples, they are by no
> means numerous. While it may be a problem worth solving, I *personally*
> don't consider it neither particularly important nor time critical.
> 
> For what it's worth, I believe Mate wants to work on clone-with once this
> RFC passes -- while there is no RFC for that, there is already an
> implementation, though from a cursory look it would require some
> adjustments to actually work with readonly properties.

I look forward to it.

I don't think the use cases for non-trivial structs (where a withX() method can 
just return new static(list all properties here) ) are as few as you think.  
One difficulty in determining that is that, if they are made easier/more robust 
(via any of the mechanisms under discussion), their usage is likely to 
increase.  That's a good thing, and a benefit of all of these pieces floating 
around, but it does make it harder to gauge the net-use of any particular 
feature.  I prefer to err on the side of enabling more flexibility and power 
rather than less.

> > It also wouldn't work with objects that need properties that are not
> > constructor arguments, such as PSR-7 type objects.  That's a no in my book.
> >
> 
> I don't understand what you mean here. Why would properties that are not
> constructor arguments be a problem?

Without clone-with, if you wanted a with-er method, it would necessarily look 
like this:

class Point {
  public function __construct(
public readonly int $x, 
public readonly int $y, 
public readonly int $z,
  ) {}

  public function withX(int $newX) {
return new static($newX, $this->y, $this->z);
  }
}

That is, you're populating the entire property set via the constructor.  In 
some cases that's fine; the larger the object, though, the more needlessly 
verbose redundancy that has.

Now let's add a "rendered" flag property, that is public readonly bool.  (Maybe 
not the best example; it's before 9 am and I'm trying to think on the fly 
here.)  It's not in the constructor, but for later processing.  It would get 
set as a side effect of some other method, to indicate the point has already 
been drawn.  Now make a new version of the object with a different Z.  What do 
you do with $rendered?

> > 3. As noted in my previous analysis, even with clone-with, asymmetric
> > visibility results in a nicer syntax when evolving objects that have any
> > complexity to them.  (See the examples in [2].)
> >
> 
> I tend to agree. And I am not opposed to having asymmetric visibility as
> well. For example, C# does both, and I think both do have value. "readonly"
> is a very strong signal to the reader. Asymmetric visibility is not.
> Asymmetric visibility (without proper readonly support) could mean that the
> property is actually readonly, or it could mean that it's exactly what it
> says on the tin: The property is internally mutable. I don't think these
> two concepts should be conflated, though they certainly have overlap.

I think this is the crux of the disagreement.  There's a large swath of cases 
that could be well-handled by either.  I feel the cases that are only or better 
handled by asymmetric visibility is larger than the cases that are only or 
better handled by readonly.  As noted above, I don't know that either of us 
have any data with which to determine which is actually the case.

(Maybe someone with more C# experience can speak to that?  What's typical 
there, where both mechanisms are available?)

> > 5. I would have to experiment a bit with hydration, as others have noted,
> > because unconventional object construction mechanis

Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Pierre Joye]

On Mon, Jun 7, 2021, 3:02 PM Nikita Popov

Regarding dependencies, does this mean that extensions should also build
> DLLs for dependency libraries themselves? Are there any concerns about
> different extensions building different versions of the same library, or
> similar?
>

This the very reason we did it ourselves, way too many issues.



> Regards,
> Nikita
>

Re: [PHP-DEV] Policy for procedural style in new additions

[Dik Takken]

On 07-06-2021 12:40, Nikita Popov wrote:
> I think that not adding new procedural mirror APIs is pretty
> uncontroversial at this point. I think one open question is regarding API
> additions to existing classes with a mirror API -- should we keep adding
> procedural functions in that case?

I guess maintaining consistency between the mirror APIs makes sense for
as long as we still have those mirror APIs.

> The more interesting question here is whether we want to deprecate existing
> APIs. From a quick look, these are the extensions that provide procedural
> mirror APIs:
> 
> date
> finfo
> intl
> mysqli
> oci8 (only partially)
> xmlwriter
> 
> I don't think I'd want to blanket deprecate all of these. I do see value in
> some of the procedural APIs (okay, only date really) or at least historical
> importance (mysqli is a migration target for mysql, which was only
> procedural). I think if we want to deprecate these, it should be on a
> case-by-case basis. For example, I see very little value in the procedural
> intl APIs.
> 
> One annoying factor here is that these mirror APIs were often added
> thoughtlessly and have design issues as a result. For example,
> xmlwriter_open_uri() makes sense, but XMLWriter::openUri() should clearly
> have been a static method, not an instance method. Similarly, mysqli_init()
> makes some sense, but mysqli::init() is entirely useless.

Deprecating the procedural APIs where it makes sense sounds like a great
step into the right direction. Historical oddities in the OO APIs could
be dealt with later.

Regards,
Dik Takken

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

RE: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Anatol Belski]

Hi,

> -Original Message-
> From: Nikita Popov 
> Sent: Monday, June 7, 2021 1:07 PM
> To: Christoph M. Becker 
> Cc: PHP internals 
> Subject: Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows
> 
> On Mon, Jun 7, 2021 at 10:58 AM Christoph M. Becker
> 
> wrote:
> 
> > On 07.06.2021 at 10:02, Nikita Popov wrote:
> >
> > > On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker
> 
> > > wrote:
> >
> > >> on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
> > >> have the capacity to do these builds manually (as currently done with
> > >> the PHP 8.0 builds), I've set up an automation which does the builds on
> > >> GH action runners[1].
> > >
> > > To clarify, this builds the binary Windows release artifacts? Automating
> > > that using GH actions is great.
> >
> > Right, that is about building the relese artifacts, which will then be
> > available from .
> >
> > >> This should likely be integrated into php-src or
> > >> php-sdk, whereyby the latter needs to be forked into a php
> organization
> > >> repo as soon as possible, since there is a pending commit regarding the
> > >> exclusion of yet unsupported PGO training scenarios, and we also
> should
> > >> roll a new SDK release, and update some of the bundled tools.
> > >
> > > Is php-sdk referring to
> > https://github.com/microsoft/php-sdk-binary-tools?
> > > Having this in the PHP organization sounds reasonable, though I don't
> > > really follow your reasoning. How is the exclusion of PGO training
> > > scenarios relevant here? Is the concern here that Microsoft will not be
> > > maintaining the SDK for new PHP versions, so the PHP organization
> should
> > > take over doing that going forward?
> >
> > Indeed, Microsoft has no intentions to maintain that repo for PHP 8, so
> > we need to fork.
> >
> 
> Okay, sounds good to me. Rather than a GitHub fork, I'd suggest pushing a
> clone of the repo, and indicate the original source in the repo
> description. GitHub forks have some annoying limitations (like the
> inability to use search), which are not great for long-term forks.
> 
> 
> > >> While these builds are
> > >> automated, and mostly work well, there are sometimes issues with new
> > >> releases and the dependency libraries are rarely updated (a lot of
> > >> these[2] are ancient versions).  And although I'm planning to enable
> > >> snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
> > >> and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
> > >> to spend much time to help with resolving issues.  In my opinion, it
> > >> would be beneficial to push the burden of providing Windows builds to
> > >> the extension maintainers.  There are already AppVeyor integrations for
> > >> several PECL extensions, some of them producing binaries which are
> > >> basically identical to the PECL builds, and generally Windows CI should
> > >> be helpful for package maintainers to detect potential issues before
> new
> > >> releases.  Furthermore, extensions maintainers would be more flexible
> > >> regarding the supported PHP version (currently, the PECL builds are
> done
> > >> for PHP 7.3, 7.4 and 8.0 only).
> > >
> > > I see some possible complications here, mainly around storage and
> > > accessibility of the produced artifacts. Artifacts produced by AppVeyor
> > are
> > > only stored for one month and not easily found. A nice thing about the
> > > current system is that the artifacts for all extensions can be found in
> > one
> > > central place.
> > >
> > > The minimum would be to move artifacts from AppVeyor into GitHub
> release
> > > artifacts to make sure they're persistent, which is rather tedious
> > without
> > > some automation (there are >16 Windows release artifacts for apcu).
> >
> > AppVeyor (and other CI providers) allows to upload artifacts to
> > arbitrary locations; at least AppVeyor supports uploading of artifacts
> > to GH realeases[1], so this could be automated.  I'd be very surprised,
> > if other GH CI providers wouldn't support that as well.
> >
> > [1] 
> >
> 
> Okay, that looks nice, and should make producing Windows builds a matter
> of
> creating a GitHub tag. Do you know if any PHP ext already uses this, so it
> could be seen in action?
> 
> > Regarding dependencies, does this mean that extensions should also build
> > > DLLs for dependency libraries themselves? Are there any concerns about
> > > different extensions building different versions of the same library, or
> > > similar?
> >
> > Oh, right, that could be an issue.  Maybe we should stick with providing
> > the dependencies from windows.php.net?  Not sure how to handle the
> > details, though.  This doesn't look super urgent to me, but I would like
> > to see more (Windows) CI integrations of the package repos soon.
> > Reusable, publicly available GH actions might make CI integration for
> > packages super simple even on Windows.

Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Nikita Popov]

On Mon, Jun 7, 2021 at 10:58 AM Christoph M. Becker 
wrote:

> On 07.06.2021 at 10:02, Nikita Popov wrote:
>
> > On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker 
> > wrote:
>
> >> on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
> >> have the capacity to do these builds manually (as currently done with
> >> the PHP 8.0 builds), I've set up an automation which does the builds on
> >> GH action runners[1].
> >
> > To clarify, this builds the binary Windows release artifacts? Automating
> > that using GH actions is great.
>
> Right, that is about building the relese artifacts, which will then be
> available from .
>
> >> This should likely be integrated into php-src or
> >> php-sdk, whereyby the latter needs to be forked into a php organization
> >> repo as soon as possible, since there is a pending commit regarding the
> >> exclusion of yet unsupported PGO training scenarios, and we also should
> >> roll a new SDK release, and update some of the bundled tools.
> >
> > Is php-sdk referring to
> https://github.com/microsoft/php-sdk-binary-tools?
> > Having this in the PHP organization sounds reasonable, though I don't
> > really follow your reasoning. How is the exclusion of PGO training
> > scenarios relevant here? Is the concern here that Microsoft will not be
> > maintaining the SDK for new PHP versions, so the PHP organization should
> > take over doing that going forward?
>
> Indeed, Microsoft has no intentions to maintain that repo for PHP 8, so
> we need to fork.
>

Okay, sounds good to me. Rather than a GitHub fork, I'd suggest pushing a
clone of the repo, and indicate the original source in the repo
description. GitHub forks have some annoying limitations (like the
inability to use search), which are not great for long-term forks.


> >> While these builds are
> >> automated, and mostly work well, there are sometimes issues with new
> >> releases and the dependency libraries are rarely updated (a lot of
> >> these[2] are ancient versions).  And although I'm planning to enable
> >> snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
> >> and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
> >> to spend much time to help with resolving issues.  In my opinion, it
> >> would be beneficial to push the burden of providing Windows builds to
> >> the extension maintainers.  There are already AppVeyor integrations for
> >> several PECL extensions, some of them producing binaries which are
> >> basically identical to the PECL builds, and generally Windows CI should
> >> be helpful for package maintainers to detect potential issues before new
> >> releases.  Furthermore, extensions maintainers would be more flexible
> >> regarding the supported PHP version (currently, the PECL builds are done
> >> for PHP 7.3, 7.4 and 8.0 only).
> >
> > I see some possible complications here, mainly around storage and
> > accessibility of the produced artifacts. Artifacts produced by AppVeyor
> are
> > only stored for one month and not easily found. A nice thing about the
> > current system is that the artifacts for all extensions can be found in
> one
> > central place.
> >
> > The minimum would be to move artifacts from AppVeyor into GitHub release
> > artifacts to make sure they're persistent, which is rather tedious
> without
> > some automation (there are >16 Windows release artifacts for apcu).
>
> AppVeyor (and other CI providers) allows to upload artifacts to
> arbitrary locations; at least AppVeyor supports uploading of artifacts
> to GH realeases[1], so this could be automated.  I'd be very surprised,
> if other GH CI providers wouldn't support that as well.
>
> [1] 
>

Okay, that looks nice, and should make producing Windows builds a matter of
creating a GitHub tag. Do you know if any PHP ext already uses this, so it
could be seen in action?

> Regarding dependencies, does this mean that extensions should also build
> > DLLs for dependency libraries themselves? Are there any concerns about
> > different extensions building different versions of the same library, or
> > similar?
>
> Oh, right, that could be an issue.  Maybe we should stick with providing
> the dependencies from windows.php.net?  Not sure how to handle the
> details, though.  This doesn't look super urgent to me, but I would like
> to see more (Windows) CI integrations of the package repos soon.
> Reusable, publicly available GH actions might make CI integration for
> packages super simple even on Windows.  Any help welcome!
>

Right. I think a problem here is that the AppVeyor configuration for
extensions is a bit arcane (at least to me). If one could just pick up a
centrally maintained action from the GH marketplace, put in your target PHP
versions and let the magic happen, that would make things simpler.

Regards,
Nikita

Re: [PHP-DEV] [RFC][Draft] Add json_encode indent parameter

[Nikita Popov]

On Thu, Jun 3, 2021 at 6:11 PM Timon de Groot  wrote:

> Hi internals,
>
> I'd like to present my RFC for adding the indent parameter to the
> json_encode function:
>https://wiki.php.net/rfc/json_encode_indentation
>
> The `string|int $indent = 4` parameter adds the ability to specify the
> indentation for
> the JSON encoder. Amount of spaces can be specified by a number and a
> string can be
> specified to set a custom indentation like `\t` or whatever.
>
> As this is my first RFC (and contribution) for PHP, I'm all kind of new
> to the process, standards, etc.
> Please let me know if I could do something better.
>
> Looking forward to feedback/input on the RFC.
>

As has been brought up in
https://github.com/php/php-src/pull/7093#issuecomment-855170601, the string
version of the $indent parameter allows you to create invalid JSON,
something that json_encode() does not currently allow. I tend to agree that
it would make sense to validate that the indent only contains whitespace
characters, and not 🚀.

Regards,
Nikita

Re: [PHP-DEV] Policy for procedural style in new additions

[Nikita Popov]

On Thu, Jun 3, 2021 at 8:28 PM Mel Dafert  wrote:

> Hi internals,
> After the RFC to add IntlDatePatternGenerator () was accepted, it was
> brought up that the duplication of
> procedural and OO style was not necessarily/useful anymore.
> This already has some (old) precedent - in 2012, UConverter was added to
> ext/intl
> (https://wiki.php.net/rfc/uconverter) and in 2014 IntlChar
> (https://wiki.php.net/rfc/intl.char) - both of which only provide a
> class, but not the
> procedural API.
> This was also shortly discussed on the mailing list for IntlChar:
> https://externals.io/message/79146#79167 after which the procedural API
> was dropped without much ado.
>
> When I wrote the IntlDatePatternGenerator RFC, I was not aware that the
> procedural API was viewed as deprecated, nor that there had been additions
> to
> ext/intl that were purely OO.
> In the thread after its vote, it was also suggested that we add a policy
> that
> forbids new additions from adding duplicated APIs, and that OO style should
> be preferred if possible. I am not sure if I am the best person to write
> such an RFC,
> but I wanted to bring this to its own thread and provide the context I
> have dug up so
> far.
>
> The duplication of the OO and procedural API dates back to the addition of
> the intl
> extension to core. There is some discussion about it in this thread from
> 2008:
> https://externals.io/message/36775
> (ignore the unrelated discussion about PHP6)
> The main argument at this point was that OO in PHP is a new thing, and
> that while
> the OO API is objectively better, the procedural API should also be there
> to
> lessen the learning curve for existing PHP users that are not yet familiar
> with OOP.
> I would argue that 13 years later, this argument no longer holds - anyone
> who
> has used PHP at some point since then most likely has encountered classes.
>
> One open question that still remains is what we do with the already
> existing
> procedural API.
> Should it be deprecated? Should it only be soft-deprecated, in that we
> mention in the
> documentation that the OO style is preferred, but that the procedural API
> is
> not planned to be removed?
> Should we just leave the procedural API as-is and live with the fact that
> some
> classes have procedural counterparts
> and some don't?
> I would personally lean towards (at least soft-) deprecation just for
> consistency,
> but I would like to hear what you would have to say.


I think that not adding new procedural mirror APIs is pretty
uncontroversial at this point. I think one open question is regarding API
additions to existing classes with a mirror API -- should we keep adding
procedural functions in that case?

The more interesting question here is whether we want to deprecate existing
APIs. From a quick look, these are the extensions that provide procedural
mirror APIs:

date
finfo
intl
mysqli
oci8 (only partially)
xmlwriter

I don't think I'd want to blanket deprecate all of these. I do see value in
some of the procedural APIs (okay, only date really) or at least historical
importance (mysqli is a migration target for mysql, which was only
procedural). I think if we want to deprecate these, it should be on a
case-by-case basis. For example, I see very little value in the procedural
intl APIs.

One annoying factor here is that these mirror APIs were often added
thoughtlessly and have design issues as a result. For example,
xmlwriter_open_uri() makes sense, but XMLWriter::openUri() should clearly
have been a static method, not an instance method. Similarly, mysqli_init()
makes some sense, but mysqli::init() is entirely useless.

Regards,
Nikita

Re: [PHP-DEV] Disable autovivification on false

[Nikita Popov]

On Sun, Jun 6, 2021 at 12:14 AM tyson andre 
wrote:

> Hi Kamil,
>
> > I have reworked the RFC based on some feedback. The improved RFC now will
> > hold 2 votes. One vote to decide whether the behaviour should be
> deprecated
> > from false, and another from null.
> >
> > If there are no objections then I would like to start the votes in a
> couple
> > of days.
> >
> > However, I would still like to hear from you whether you
> > use autovivification from false and/or null in your projects. So far, I
> was
> > not able to identify when this would be useful in real-life scenarios.
> >
> > RFC: https://wiki.php.net/rfc/autovivification_false
>
> Without an implementation it'd be hard to actually tell what the impact
> would be. There isn't one linked to from the RFC or on
> github.com/php/php-src.
> You might have code in your application or external dependencies that
> relies on that without you remembering or being aware of it for null.
>
> **I started working on a prototype independently just to get an idea of
> how many things would encounter deprecations. See
> https://github.com/TysonAndre/php-src/pull/17** (I am not one of the
> RFC's authors. If someone bases their implementation on that prototype PR
> please keep the authorship of initial commits (e.g. `Co-Authored-By` in git)
>
> Also, what is the planned deprecation message, what about documenting all
> kinds of expressions that can cause autovivication, etc: e.g. `$x =
> &$falseVar['offset']`
>
>
> My assumption is that false would be reasonably practical to implement
> (this patch with `== IS_FALSE` instead of `>= IS_NULL`, plus some changes
> to the optimizer to account for the fact some dimension assignment
> statements might now have.
> For IS_NULL, that would probably require more familiarity with php's
> internals than I have to be certain the implementation is correct and to
> properly distinguish between undefined and null when automatically creating
> properties.
>

This is a good point. After a cursory look, it's not obvious to me how we
could distinguish these cases. We do need to perform the null
initialization here, as we can't just leave behind an undef element in the
property table.

I think it would be best to limit this proposal to the false case only. A
way to put this is that auto-vivification only happens for !isset(), which
is precisely undef or null, but not false. (The historical behavior was
that it happens for empty(), which has been cut down over time to the point
that false is the only other accepted value, at which point this framing
doesn't make sense anymore.)

Regards,
Nikita

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Pierre Joye]

Hj Remi! :)

On Mon, Jun 7, 2021, 3:01 PM Remi Collet  wrote:

> Le 04/06/2021 à 16:36, Ben Morss via internals a écrit :
>
> > ... I created a PR to propagate libgd's AVIF
> > support into PHP's bundled gd fork...
>
> Does it really make sense to keep maintaining this fork ?
>
> Having to maintain 2 (quite) different code and picking
> piece from one to other seems a waste of energy.
>
> I really think that we'll need to re-sync bundled gd
> with upstream and only keep it as an alternative for
> people without system gd (and perhaps even drop it later)
>


it is more or less the same.

If we want to drop the use of php malloc, could be easy then.

but this is not the topic of this discussion though  ")


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

Re: [PHP-DEV] [RFC] Readonly properties

[Nikita Popov]

On Sat, Jun 5, 2021 at 6:51 PM Larry Garfield 
wrote:

> On Fri, Jun 4, 2021, at 10:19 AM, Nikita Popov wrote:
> > Hi internals,
> >
> > I'd like to open the discussion on readonly properties:
> > https://wiki.php.net/rfc/readonly_properties_v2
> >
> > This proposal is similar to the
> > https://wiki.php.net/rfc/write_once_properties RFC that has been
> declined
> > previously. One significant difference is that the new RFC limits the
> scope
> > of initializing assignments. I think a key mistake of the previous RFC
> was
> > the confusing "write-once" framing, which is both technically correct and
> > quite irrelevant.
> >
> > Please see the rationale section (
> > https://wiki.php.net/rfc/readonly_properties_v2#rationale) for how this
> > proposal relates to other RFCs and alternatives.
> >
> > Regards,
> > Nikita
>
> Thank you for the detailed analysis in the rationale section.  I am,
> however, still skeptical of this approach, for a couple of reasons.
>
> 1. This does appear to address the "leakage" problem I noted in my earlier
> analysis around the start of the year, when considering the writeonce
> proposal[1][2].  That's great to see.
>
> 2. It doesn't address the larger question of cloning, however.  The answer
> for now seems "maybe we'll get clone-with at some point", which would be a
> way around it, but there is no active RFC for that right now.  I'm
> obviously very in favor of RFCs that complement each other to give more
> than the sum of their parts, but those RFCs need to be at least on the
> horizon to actually come together.  Right now that looks like it won't
> happen this cycle.  Absent clone-with, readonly would be effectively
> unusable in any evolvable object of any non-trivial complexity.


Compared to the general area of applicability of readonly properties, the
cases that require clone-with are rare. It's the intersection of
"not-really-immutable objects using wither evolution" and "has so many
properties that passing them to the constructor is infeasible". While this
intersection does include a couple of prominent examples, they are by no
means numerous. While it may be a problem worth solving, I *personally*
don't consider it neither particularly important nor time critical.

For what it's worth, I believe Mate wants to work on clone-with once this
RFC passes -- while there is no RFC for that, there is already an
implementation, though from a cursory look it would require some
adjustments to actually work with readonly properties.


> It also wouldn't work with objects that need properties that are not
> constructor arguments, such as PSR-7 type objects.  That's a no in my book.
>

I don't understand what you mean here. Why would properties that are not
constructor arguments be a problem?


> 3. As noted in my previous analysis, even with clone-with, asymmetric
> visibility results in a nicer syntax when evolving objects that have any
> complexity to them.  (See the examples in [2].)
>

I tend to agree. And I am not opposed to having asymmetric visibility as
well. For example, C# does both, and I think both do have value. "readonly"
is a very strong signal to the reader. Asymmetric visibility is not.
Asymmetric visibility (without proper readonly support) could mean that the
property is actually readonly, or it could mean that it's exactly what it
says on the tin: The property is internally mutable. I don't think these
two concepts should be conflated, though they certainly have overlap.


> 4. One detail left out of the rationale section is how much of a
> performance difference there is between readonly and implicit-accessors.
> It says the latter still has a performance hit, but not how much.  How
> significant is it?  If it's tiny,  then frankly the biggest argument for
> readonly goes away, since implicit-accessors gives us 98% the same
> functionality in a more forward-compatible way without the cloning issues.
> If it's twice as slow, then having a separate keyword for a common case
> makes sense.
>

The performance difference shouldn't be large, maybe 10-15%. I don't
consider performance a big deciding factor here. When comparing to
accessors the relevant difference I see is that readonly properties cover a
large use case at a small fraction of language complexity.


> 5. I would have to experiment a bit with hydration, as others have noted,
> because unconventional object construction mechanisms are a critically
> important workflow.  The RFC even notes in passing that serialization is
> possibly made complicated.  Just how complicated?  There's no mention of
> __deserialize() and how it would interact, but cases like that need to be
> very clearly handled and documented.
>

The RFC notes in passing that *if* readonly default values were allowed, it
could have impact on userland deserialization. As-is, I believe the
proposal doesn't present any problem for userland hydrators or
deserializers, or PHP's own unserialization mechanisms. This should get
mentioned in the pr

Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Christoph M. Becker]

On 07.06.2021 at 10:02, Nikita Popov wrote:

> On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker 
> wrote:

>> on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
>> have the capacity to do these builds manually (as currently done with
>> the PHP 8.0 builds), I've set up an automation which does the builds on
>> GH action runners[1].
>
> To clarify, this builds the binary Windows release artifacts? Automating
> that using GH actions is great.

Right, that is about building the relese artifacts, which will then be
available from .

>> This should likely be integrated into php-src or
>> php-sdk, whereyby the latter needs to be forked into a php organization
>> repo as soon as possible, since there is a pending commit regarding the
>> exclusion of yet unsupported PGO training scenarios, and we also should
>> roll a new SDK release, and update some of the bundled tools.
>
> Is php-sdk referring to https://github.com/microsoft/php-sdk-binary-tools?
> Having this in the PHP organization sounds reasonable, though I don't
> really follow your reasoning. How is the exclusion of PGO training
> scenarios relevant here? Is the concern here that Microsoft will not be
> maintaining the SDK for new PHP versions, so the PHP organization should
> take over doing that going forward?

Indeed, Microsoft has no intentions to maintain that repo for PHP 8, so
we need to fork.

>> While these builds are
>> automated, and mostly work well, there are sometimes issues with new
>> releases and the dependency libraries are rarely updated (a lot of
>> these[2] are ancient versions).  And although I'm planning to enable
>> snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
>> and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
>> to spend much time to help with resolving issues.  In my opinion, it
>> would be beneficial to push the burden of providing Windows builds to
>> the extension maintainers.  There are already AppVeyor integrations for
>> several PECL extensions, some of them producing binaries which are
>> basically identical to the PECL builds, and generally Windows CI should
>> be helpful for package maintainers to detect potential issues before new
>> releases.  Furthermore, extensions maintainers would be more flexible
>> regarding the supported PHP version (currently, the PECL builds are done
>> for PHP 7.3, 7.4 and 8.0 only).
>
> I see some possible complications here, mainly around storage and
> accessibility of the produced artifacts. Artifacts produced by AppVeyor are
> only stored for one month and not easily found. A nice thing about the
> current system is that the artifacts for all extensions can be found in one
> central place.
>
> The minimum would be to move artifacts from AppVeyor into GitHub release
> artifacts to make sure they're persistent, which is rather tedious without
> some automation (there are >16 Windows release artifacts for apcu).

AppVeyor (and other CI providers) allows to upload artifacts to
arbitrary locations; at least AppVeyor supports uploading of artifacts
to GH realeases[1], so this could be automated.  I'd be very surprised,
if other GH CI providers wouldn't support that as well.

[1] 

> Regarding dependencies, does this mean that extensions should also build
> DLLs for dependency libraries themselves? Are there any concerns about
> different extensions building different versions of the same library, or
> similar?

Oh, right, that could be an issue.  Maybe we should stick with providing
the dependencies from windows.php.net?  Not sure how to handle the
details, though.  This doesn't look super urgent to me, but I would like
to see more (Windows) CI integrations of the package repos soon.
Reusable, publicly available GH actions might make CI integration for
packages super simple even on Windows.  Any help welcome!

Christoph

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

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Nikita Popov]

On Mon, Jun 7, 2021 at 10:01 AM Remi Collet  wrote:

> Le 04/06/2021 à 16:36, Ben Morss via internals a écrit :
>
> > ... I created a PR to propagate libgd's AVIF
> > support into PHP's bundled gd fork...
>
> Does it really make sense to keep maintaining this fork ?
>
> Having to maintain 2 (quite) different code and picking
> piece from one to other seems a waste of energy.
>
> I really think that we'll need to re-sync bundled gd
> with upstream and only keep it as an alternative for
> people without system gd (and perhaps even drop it later)
>

Once https://github.com/libgd/libgd/pull/692 lands, the goal would indeed
be to switch away from using a gd fork to bundling an unpatched upstream gd
(and maybe unbundling in the future). This is not entirely easy as the
codebases have diverged, but custom allocators are the current technical
blocker.

Regards,
Nikita

Re: [PHP-DEV] PHP 8.1 and PECL ext builds for Windows

[Nikita Popov]

On Sun, Jun 6, 2021 at 3:26 PM Christoph M. Becker 
wrote:

> Hi all,
>
> on Tuesday, PHP 8.1.0alpha1 is supposed to be tagged, and since I don't
> have the capacity to do these builds manually (as currently done with
> the PHP 8.0 builds), I've set up an automation which does the builds on
> GH action runners[1].


To clarify, this builds the binary Windows release artifacts? Automating
that using GH actions is great.


> This should likely be integrated into php-src or
> php-sdk, whereyby the latter needs to be forked into a php organization
> repo as soon as possible, since there is a pending commit regarding the
> exclusion of yet unsupported PGO training scenarios, and we also should
> roll a new SDK release, and update some of the bundled tools.
>

Is php-sdk referring to https://github.com/microsoft/php-sdk-binary-tools?
Having this in the PHP organization sounds reasonable, though I don't
really follow your reasoning. How is the exclusion of PGO training
scenarios relevant here? Is the concern here that Microsoft will not be
maintaining the SDK for new PHP versions, so the PHP organization should
take over doing that going forward?

Anyhow, if these PHP 8.1 builds turn out to be good, I'd also like to do
> the PHP 8.0 builds this way; this would free required capacities on the
> current build machine (plus save a bit of my time), which is actually
> supposed to do the PECL extension builds.


Automating PHP 8.0 builds sounds good as well.


> While these builds are
> automated, and mostly work well, there are sometimes issues with new
> releases and the dependency libraries are rarely updated (a lot of
> these[2] are ancient versions).  And although I'm planning to enable
> snapshot builds when PHP 8.1 enters the beta release cycle (as usual),
> and to do the mass rebuild after PHP 8.1.0 is released, I won't be able
> to spend much time to help with resolving issues.  In my opinion, it
> would be beneficial to push the burden of providing Windows builds to
> the extension maintainers.  There are already AppVeyor integrations for
> several PECL extensions, some of them producing binaries which are
> basically identical to the PECL builds, and generally Windows CI should
> be helpful for package maintainers to detect potential issues before new
> releases.  Furthermore, extensions maintainers would be more flexible
> regarding the supported PHP version (currently, the PECL builds are done
> for PHP 7.3, 7.4 and 8.0 only).
>

I see some possible complications here, mainly around storage and
accessibility of the produced artifacts. Artifacts produced by AppVeyor are
only stored for one month and not easily found. A nice thing about the
current system is that the artifacts for all extensions can be found in one
central place.

The minimum would be to move artifacts from AppVeyor into GitHub release
artifacts to make sure they're persistent, which is rather tedious without
some automation (there are >16 Windows release artifacts for apcu).

Regarding dependencies, does this mean that extensions should also build
DLLs for dependency libraries themselves? Are there any concerns about
different extensions building different versions of the same library, or
similar?

Regards,
Nikita

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Remi Collet]

Le 04/06/2021 à 16:36, Ben Morss via internals a écrit :


... I created a PR to propagate libgd's AVIF
support into PHP's bundled gd fork...


Does it really make sense to keep maintaining this fork ?

Having to maintain 2 (quite) different code and picking
piece from one to other seems a waste of energy.

I really think that we'll need to re-sync bundled gd
with upstream and only keep it as an alternative for
people without system gd (and perhaps even drop it later)


My 0.02cts

Remi

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

Re: [PHP-DEV] Propagating AVIF support from libgd into PHP's bundled gd

[Nikita Popov]

On Sat, Jun 5, 2021 at 11:09 PM Ayesh Karunaratne  wrote:

> Hi Ben,
> Thank you for opening this PR and the discussion. With the wide
> availability of AVIF/AV1 support in browsers, I think this will fit
> nicely.
>

Yes, this looks like a reasonable addition. Effectively this is just a sync
with upstream libgd, and the exposed API follows existing conventions.


> We have the Namespaces in Bundled Extensions RFC
> (https://wiki.php.net/rfc/namespaces_in_bundled_extensions) passed, so
> perhaps, the new functions are probably better in the `Gd` namespace?
> This would mean the new functions would be `\Gd\imagecreatefromavif`
> and `\Gd\imageavif`. They are inconsistent with the existing functions
> of course, but I thought to mention it because it's a recent proposal
> and I don't think we added new functions after that RFC. Some examples
> are recently renamed PHP classes in IMAP, Pgsql, LDAP, and FTP
> extensions to follow this new proposal.>
>

See
https://wiki.php.net/rfc/namespaces_in_bundled_extensions#existing_non-namespaces_symbols_and_consistency
:
> When adding new symbols to existing extensions, it is more important to
be consistent with existing symbols than to follow the namespacing
guidelines.

Unless we introduce namespaced aliases for the gd extension first, these
functions should not be namespaced either. As Mark pointed out, in the case
of GD it might make more sense to move to an OO API rather than a new set
of namespaced functions. In any case, I don't think this is the place to
discuss this.

Regards,
Nikita