[PHP-DEV] Re: [RFC] OOP API for cURL extension

[Sara Golemon]

Summarizing replies so far.  Won't be able to update the RFC immediately as
my day job needs me, but some great discussions already, gang. Thanks!

* Define the conditions under which exceptions will be thrown (and which
exceptions) - I'll add these to the RFC, but in short:
  * CurlException - Never, it's an interface type to group the other
exceptions.
  * CurlHandleException - Whenever a CurlHandle::method() fails (in lieu of
returning false)
  * CurlMultiException - Same, but for the CurlMultiHandle class.
  * CurlShareException - Same, but for the CurlShareHandle class.

* Naming styles, e.g getErrorNumber(): int   vs   errno()
  Comment: Agreed with your points.  We don't have to stick to a hard line
mapping of the function names.  My initial translation did because my
bugbear is with the lack of fluency and all the rest is just window
dressing on that.
  Proposal: I'll rename all the new APIs according to a get*/set* scheme
without abbreviations, e.g.:
  * CurlHandle::getErrorNumber(): int
  * CurlHandle::getError(): ?string
  * static CurlHandle::getErrorTextFromCode(int $code): ?string
  * CurlHandle::execute(): ?string  // See late note about exec return
values
  * CurlHandle::setOptionInt(int $option, int $value): CurlHandle

* Better typing for setOpt() methods.
  Comment: Yep, this is a good and fair point.  It's going to take a little
more dicing up of the current implementation, but hopefully not too rough.
  Proposal: Keep untyped setOption() method (1/ Easier migration of
existing code, 2/ Some options may prove difficult to type), but add:
  * CurlHandle::setOptionBool(int $option, bool $value): CurlHandle
  * CurlHandle::setOptionInt(int $option, int $value): CurlHandle
  * CurlHandle::setOptionString(int $option, string $value): CurlHandle
  * etc... as needed, will this get weird when we get to Array since there
IS a setOptArray?  Maybe we just don't mirror that one, or we call it
setOptionMany(). Yeah, I like Many for the multiple option set, and Array
for the single option of array type.
  Internally, the setopt handler will be split by type so that each typed
setting can call explicitly, and the untyped one can call all.

* CurlHandle::exec() mixed typing of return values.
  Comment: Agreed.  The `true` return value becomes meaningless in the
RETURNTRANSFER==false case.
  Proposal: Update the RFC for CurlHandle::execute() to return ?string.

* https://php.watch/articles/php-curl-security-hardening
  Comment: I'll read this later when I'm updating the RFC.

* Prefer class constants to global constants.
  Comment: I'm less compelled by this.  The global scope is polluted with
the constants whether we add copies or not.  Adding a second way to spell
the constant name only adds a second way to spell the constant name.
  Proposal: Change my mind?

* Request and Response objects, along the lines of PSR-18
  Comment: I'd be in favor of that, but it's not the mountain I'm
personally trying to climb today.  No offense taken if you vote no because
this isn't enough, but I don't have the cycles to go in that hard.
   Proposal: Write an RFC (and get it passed) and I can probably help you
implement it?

-Sara

[RFC] OOP API for cURL extension

[Sara Golemon]

Good afternoon folks, I'd like to open discussion on adding OOP APIs to the
cURL extension.
https://wiki.php.net/rfc/curl-oop

This has been a long standing bug-bear of mine, and I think its time has
come.

try {
  (new \CurlHandle)->setOpt(YOUR_VOTE, true)->exec();
} catch (\CurlHandleException $ex) {
  assert(false); // Why not?!
}

-Sara

Re: [PHP-DEV] [RFC][Vote] RFC1867 for non-POST HTTP verbs

[Sara Golemon]

On Mon, Jan 22, 2024 at 1:24 AM Ilija Tovilo  wrote:

> I started the vote on the "RFC1867 for non-POST HTTP verbs" RFC.
> https://wiki.php.net/rfc/rfc1867-non-post
>
>
Apologies for not seeing the discussion period, but I'll qualify my "No"
vote, because I'm actually +1 on the general concept, and this is just a
little bikeshedding (this RFC will pass even with a no vote from me).

1/ This function reaches into the SAPI to pull out the "special" body
data.  That's great, but what about uses where providing an input string
makes sense.  For that, and for point 2, I'd suggest
`http_parse_query(string $query, ?array $options = null): array|object`.

2/ `request_` represents a new psuedo-namespace, functions are easier to
find and associate if we keep them grouped.  I recommend 'http_` because it
compliments the very related function `http_build_query()`, and for the
version of this function which refers directly to the request:
`http_parse_request(?array $options = null) : array|object`.

-Sara

Re: [PHP-DEV] Dedicated StreamBucket class

[Sara Golemon]

On Sat, Jan 13, 2024 at 1:29 AM Máté Kocsis  wrote:

> Recently, I realized that the stream_bucket_new() and
> stream_bucket_make_writeable() functions
> create stdClass instances by dynamically adding a "bucket", a "data" and a
> "datalen" property to it.
>

I don't want to stand in the way of you improving this part of Streams, and
I'm really not commenting on your PR at all. BUT I would like to
formally ask/give-permission to just redesign file I/O in PHP altogether.
This would be a nice feature drop for 9.0, and we could deprecate the old
stuff in 10, remove it in 12?

No disrespect to all the folks (including myself) who had a part in file
I/O as it exists today, but it *IS* a hot mess.  I've sketched out
redesigns with folks over the years, but I have to be honest that I don't
have the spoons to invest in Stream 2.0, nor do most of the
fellow-grayhairs I've chatted with about it.

So please, if you at all feel inclined, burn this psuedo-posix I/O hell we
have to the ground and replace it with the gleaming phoenix that PHP
deserves.

-Sara

Re: [PHP-DEV] Add security.txt file to php.net

[Sara Golemon]

On Thu, Sep 28, 2023 at 5:20 PM Ben Ramsey  wrote:
> I've added documentation inline in the security.txt file
>

To add some nitpicky bikeshedding, I'd put those instructions elsewhere
(maybe php-src:docs/release-process.md ?) and only have a single line in
the security.txt file referring out to that.  The focus of the security.txt
file should BE the metadata.

+1 on the concept, and I do like the idea of making it part of the new
branch release process as well as having one of the new RMs being the ones
to sign it.

-Sara

Re: [PHP-DEV] RFC [Discussion]: Marking overridden methods (#[\Override])

[Sara Golemon]

On Thu, May 11, 2023 at 11:37 AM Tim Düsterhus  wrote:
>
> I'm now opening discussion for the RFC "Marking overridden methods
> (#[\Override])":
>

I 100% get the intent behind this RFC, and as someone who's used this in
multiple other languages the benefit to defensive coding is obvious.

Thoughts:

I think targeting 8.3 is aggressive as we're less than a month from FF
(accounting for discussion and voting period).


The first argument (about not impacting callers) for "why an attribute and
not a keyword" feels like it's tying itself into a knot to make a specious
point.  The second argument about FC is more defensible, though I
personally think it's not merited in this particular case.  I'd personally
rather have a keyword here.


If you do go with an Attribute, then I'd go ahead and go further by
allowing to specify the name of the class being overridden and possibly
flags about intentional LSP violations.  For examples:


// Intentional LSP violations
class A {
  public function foo(): \SimpleXMLElement { return
simplexml_load_file("/tmp/file.xml"); }
}
class TestA extends A {
  #[\Override(Override::IGNORE_RETURN_TYPE_VIOLATION)]
  public function foo(): TestProxyClass { return TestProxy(parent::foo()); }
}

LSP checks are super valuable for writing clean and well debuggable code,
but sometimes they get in the way of mocking or some other non-production
activity.  This could provide a "get out of jail free card" for those
circumstances where you just want to tell the engine, "Shut up, I know what
I'm doing".



// Specific parent override
class A {
  public function foo() { return 1; }
}
class B extends A {
  // Not present in older versions of library, just added by maintainers.
  public function foo() { return bar(); }
}
class C extends B {
  // Errors because we're now overriding B::foo(), not A::foo().
  #[\Override(A::class)]
  public function foo() { return parent::foo() + 1; }
}

C was written at a time before B::foo() was implemented and makes
assumptions about its behavior.  Then B adds their of foo() which breaks
those assumptions.  C gets to know about this more quickly because the
upgrade breaks those assumptions.  C should only use this subfeature in
places where the inheritance hierarchy matters (such as intentional LSP
violations).


Just my initial thoughts, overall +1 on your proposal.

-Sara

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

[Sara Golemon]

On Tue, Apr 11, 2023 at 9:29 AM Jeffrey Dafoe  wrote:

> Essentially the same thing here. Removal of dynamic properties will be the
> next big one for my team. It's the deprecations that hit huge swaths of
> code without really offering much benefit that are annoying.
>
> Yes, we have a _lot_ of classes. Also multiple versions of Zend framework
> that we backport to. However, I see in a subsequent email that this is in
> preparation for improvements, which makes it more tolerable.
>
>
To clarify; Are you saying that you have a _lot_ of classes _which make use
of dynamic properties_?  A class where properties are predefined is
unimpacted by this.  stdClass is also unimpacted (as it implicitly has
allowdynamicproperties).  The only classes you should need to add the
attribute to are ones where you're using them, essentially, as typed
associative arrays.

I'm surprised if that's what you have, because it seems like a lot of extra
effort to give names to what are essentially anonymous structures.  The
advantage of providing a name should be that you get to know what
properties will be present (and perhaps that the values therein are
validated or typed themselves).

Can you expand a bit more on your use-case?

-Sara

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

[Sara Golemon]

On Tue, Apr 11, 2023 at 9:18 AM Robert Landers 
wrote:

> > You can add `#[AllowDynamicProperties]` to classes where you want to
> allow
> > dynamic properties.
>
> I don't think that will work in PHP 9?
>
>
In Niki's earliest draft, he wanted to completely remove dynamic properties
from *default* class handlers in 9.0, as this would simplify the most
common use-case for classes and objects and improve their runtime
efficiency.  Even in this case, however, the stdClass specialization would
have dynamic properties implemented in a way which would allow an escape
hatch for user classes via extending stdClass.

We wound up with the attribute approach instead, which means that the logic
for dynamic properties, as well as the allocation overhead, still has to
exist in all userland classes.  All approaches however, came with stdClass
working as expected out of the box, and a low-effort, forward-compatible
escape hatch for those rare cases where dynamic properties are needed on
custom classes.

This is because PHP's dedication to stability IS, AND REMAINS, steadfast
and fanatical.

-Sara

Re: [PHP-DEV] [RFC] New core autoloading mechanism with support for function autoloading

[Sara Golemon]

> On Apr 10, 2023, at 07:17, G. P. B.  wrote:
> 
> Hello Internals,
> 
> Dan and I would like to propose a new core autoloading mechanism that fixes
> some minor design issues with the current class autoloading mechanism and
> introduce a brand-new function autoloading mechanism:
> https://wiki.php.net/rfc/core-autoloading

At a high level: +1, would vote for again (I think I voted for this last time 
it came up...)

Initial thoughts, mostly based on replies so far:

1/ There's certainly some bike-shedding for the names to do.  Good points have 
already been made and I won't belabor them.

2/ I'm unconcerned by the edge case brought up about load ordering as I feel 
that having multiple definitions of a single function name in an autoload 
friendly codebase grouped in files which permit this kind of shenanigans is a 
technical possibility, but a practical absurdity.  Nobody should be designing 
traps like that.

3/ Pinning concerns me a little, and we should certainly build some strong 
unittests to validate behavior here, but I'm confident that can be resolved 
during implementation.

4/ If nothing else, I just look forward to gaining consistency here.  
autoloading being exclusive to classes has long annoyed me, just not quite to 
the point of action.  :)

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

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

[Sara Golemon]

> I'm saying that the DX for writing extensions is better in other languages.

Citation needed.  Java's extension API is certainly a hot mess.  Python's is 
fine, but ultimately has similar pitfalls to PHP's. Go's looks very nice at 
first blush, but given that it's closer to an FFI than a proper extension API, 
shortfalls inevitably show up when you try to do anything complex.

I'd also point out that PHP's extension API isn't stagnant.  The stub 
generation improvement of just a few years ago significantly improved the 
process of writing extensions.

> And that these days new products come along and provide extensions for
> other languages but not PHP. Which is a problem I can only work around by
> writing an extension.

Okay. Why is this a problem?  This is what's right about OSS.  That you can 
take two things and smush 'em together because you need something from both.

> PHP now has FFI which provides an easier way to extend PHP. I have huge
> hopes for it - but in my experience it doesn't feel finished.

I agree, it's not finished.  But the problem there is also the opportunity.  
OSS works best when people who have an actual need are the ones designing the 
interfaces and making things better.

I don't pay attention to FFI because I can write PHP extensions on a my mobile, 
while sitting on an island beach and playing board games (true story).  I know 
that's not universally true, but it's why I'm not putting the effort in, 
because I'll end up building the wrong solution by not truly understanding the 
requirements (also a true story, take a look at streams sometime).

If it feels like FFI is stalled, it's probably because it's "good enough" for 
the people who got it to this point.  The itch is scratched and the need is met.

So when I call the state of FFI an opportunity, I'm not saying "code or gtfo" 
as such is sometime vilified.  I'm saying this is an open source project of the 
purest kind and it really is up to someone to care about a thing enough to put 
in the work to make it better.

And if your reply is, "But I don't know C", then good news! That's another 
opportunity.  PHP is a nice language, but it's not the only one out there.  C 
is a mother language, the payoff on learning just keeps coming around.

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

Re: [PHP-DEV] PHP Modules

[Sara Golemon]

> On Apr 10, 2023, at 20:40, Michael Morris  wrote:
> 
> This will be long.

Yes, it's long, so I'm going to focus on a couple things and not quote too much.

> I propose PHP Modules to hold new features.

What you seem to have described is improved lexical scoping.  Rather than a 
shared "global" scope for classes, functions, constants, and variables, you'd 
like to allow files, or perhaps even statement lists (open brace to closed 
brace) to work as either independent or compositional scopes.  Basically, make 
scopes in a certain mode of PHP act more like Javascript.

I'll be honest, if we could throw away PHP's old behavior and make this the 
only mode, I'd be pretty happy.  We can't of course, at best we'd have to mix 
(and yes, I know that's part of your suggestion).

This is a LOT of complexity.

Not impossible, nothing is, but I'm fairly confident it would make maintaining 
the runtime harder, and would notably slow execution.  Not saying "no", since I 
lack that power, but I do want to make it clear how HARD this feature would be 
to implement well.


> PHP Modules also would not
> parse as templates at all - no opening  that will be a headache for IDE makers, but it's not insurmountable).

I would suggest, as a compromise, keep the initial open tag (or maybe an 
alternative one, like  I hope this helps, or at least spurs a conversation to come up with
> something to address this issue.

Lastly, like the stability thread, this isn't a new suggestion, and I'd 
recommend googling back through the archives for prior discussions.  Past 
failures don't mean it won't work today... Opinions change and so does the 
runtime, but it may be helpful to understand the complexities presented by this 
strategy, and what the objections to it will likely boil down to.

See also "PHP Editions" which is a different, but closely related proposal put 
forth by Andi as recently as the 7.x era.

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

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

[Sara Golemon]

> PHP has FFI but IMO it would benefit from further development. And the
> benefits of native extensions will often be what's needed instead of FFI.

I'm sorry.  I must be misunderstanding you. Are you implying PHP has no native 
extension mechanism/API?

PHP has had a native extension API since PHP 3.  Longer technically, but only 
the PHP 3 and later APIs are still supported.

Yes. I must not have understood you.

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

Re: [PHP-DEV] base64url format

[Sara Golemon]

On Tue, Jan 10, 2023 at 8:44 AM Larry Garfield 
wrote:
>
> > Can hold a vote if anyone objects, but this seems fairly
non-controversial.
> >
>
> It sounds to me like there's enough discussion to be had on the How to
warrant a formal RFC.  I get the sense once the bikeshedding is done it
will pass, but it's going to need the discussion/review.
>

Yep, that's my reading at this point to. Expect an RFC to be inbound with
the initial feedback integrated (e.g. new funcs vs flags).

-Sara

[PHP-DEV] base64url format

[Sara Golemon]

I've been working with JWTs lately and that means working with Base64URL
format. (Ref: https://www.rfc-editor.org/rfc/rfc4648#section-5 )
This is essentially the same thing as normal Base64, but instead of '+' and
'/', it uses '-' and '_', respectively. It also allows leaving off the
training '=' padding characters.

So far, I've just been including polyfills like this:

function base64url_decode(string $str): string {
return base64_decode(str_pad(strtr($str, '-_', '+/'), (4 -
(strlen($str) % 4)) % 4, '='));
}

function base64_encode(string $str): string {
return rtrim(strtr(base64_encode($str), '+/', '-_'), '=');
}

These work fine, but they create a LOT of string copies along the way which
shouldn't be necessary.
Would anyone mind if skipped RFC and just added `base64url_encode()` and
`base64url_decode()` to PHP 8.3?

Can hold a vote if anyone objects, but this seems fairly non-controversial.

-Sara

Re: [PHP-DEV] [RFC] Unicode Text Processing

[Sara Golemon]

On Thu, Dec 15, 2022 at 9:34 AM Derick Rethans  wrote:

> I have just published an initial draft of the "Unicode Text Processing"
> RFC, a proposal to have performant unicode text processing always
> available to PHP users, by introducing a new "Text" class.
>
> You can find it at:
> https://wiki.php.net/rfc/unicode_text_processing
>
> I'm looking forwards to hearing your opinions, additions, and
> suggestions — the RFC specifically asks for these in places.
>
>
Obviously, hurdle one is making the ICU library a requirement for building
PHP.  I'd almost make that it's own milestone in this project with the
introduction of the Text class as a separate followon.  A very casual
(IANAL) read of the ICU license doesn't seem to make this a problem, so it
may be more of a question of whether we put this on people wanting to build
PHP.  ICU is pretty widely available and used, so I also don't see this as
a major stumbling block.

Question 2 is that class.  I know folks have been clammoring for a `String`
class for some time and this actually fills that niche quite well.  A part
of me wonders if we can overload it a little to provide a psuedo locale of
"binary" so that users can, optionally, treat it like a more generalized
String class in specific cases, storing a normal `char*` zend_string under
the hood in that case.  Possibly as a specialzation tree.

/* names as examples only */
interface Stringy { /* define all those APIs */ }
class Text implements Stringy { /* ... */ }
class BinaryString implements Stringy { /* ... */ }

I think you'd get a lot more buy-in from the folks who worry that UTF16 is
overhead they don't want, but who do like the idea of an OOPy string.  It
also provides a migration path to avoid having to rethink byte vs grapheme
conversions up front, instead deferring that part of a migration till later.

Overall, I'm more positive on this than negative, and I eagerly await the
rest of this thread.

-Sara

Re: [PHP-DEV] Remove PHP-x.y.* git branches

[Sara Golemon]

On Tue, Dec 13, 2022 at 12:03 PM Tim Düsterhus  wrote:
> One benefit of removing those branches would be, that usability of
> GitHub's branch selector improves, specifically the branch selector when
> creating a new PR.
>

Maybe this is my CLI privilege talking, but who's using pulldowns to select
PR branches?  Sepcifically, IME we tend to get PRs against the `master`
branch.

All that aside, I do agree that the dropdown's contents can be daunting.
It's a big list. But:

1/ We're unlikely to get rid of the release branches 100%.  The current RC
cycles have branches for their release so that we can add revisions onto
the RC and get a stable final.  So at minimum, there's going to be a
release branch in place for each active release on 16 out of 28 days
(slightly more than 50% of the time).  Sure, that's just a couple of
version specific branches instead of hundreds, and that point is well
taken, but my counterpoint is that we will have working branches.

2/ I'm not convinced this is a confusing scheme.  While php-src doesn't
follow perfect semver, we certainly have something recognizable to the
broader OSS development community, and if you see PHP-8.0 PHP-8.0.0
PHP-8.0.1 etc... I think a programmer is going to being able to sus out the
meaning of these branches.  Even if they don't, the review process will
easily be able to set them straight.  TL;DR We can expect a reasonable
amount of sense on the part of anyone who has any reason to be poking
around branches.

Given #2, I don't see a significant benefit, given #1 I see that benefit
being naturally mitigated, and I don't see removing data from our repo as
being valuable.

Just my personal feeling on the matter, don't let me discourage you from
bringing this to an RFC and holding a vote.

-Sara

Re: [PHP-DEV] Remove PHP-x.y.* git branches

[Sara Golemon]

On Tue, Dec 13, 2022 at 11:31 AM Michael Voříšek - ČVUT FJFI <
voris...@fjfi.cvut.cz> wrote:

> Hello everyone,
>
> I am the author of https://github.com/php/php-src/issues/10007 proposal
> and I would ask you for the green light to do so.
>
>
Why do you want to remove these branches?

I agree that they have minimal value especially since the tags are the
actual release commit (and for release process versions often represent a
spur off the release branch), but the cost in the repo is negligible.  What
is gained from removing information from the repository?

-Sara

Re: [PHP-DEV] Change email address associated with account

[Sara Golemon]

On Mon, Oct 31, 2022 at 2:48 PM Josh Bruce  wrote:

> I’d like to change my email address for internals but don’t want to lose
> ownership (??) of the falsifiable RFC:
> https://wiki.php.net/rfc/objects-can-be-falsifiable
>
> Is this possible? Should I be posting this somewhere else, if so, where?
>
>
If you're talking about an @php.net address, that's not trivial, but it is
doable.  Ultimately simpler to create a new account and kill the old one.

If you're just talking about mailing list subscription, then you can unsub
from the old one and resub with the new one.  Email to `
internals-subsc...@lists.php.net` and `internals-unsubscr...@lists.php.net`
from the relevant addresses and you'll be responded with a message to
bounce back and confirm.  All self-servicey.

As for the wiki, there's not /really/ such a thing as "ownership" of an RFC
in a formal sense.  Anyone with wiki karma can edit any RFC, there's just a
gentleperson's agreement to not edit the RFCs of others without their
permission.  So again, if you get a new wiki account, and kill the old one,
that's sufficient.

-Sara

Re: [PHP-DEV] One-line heredoc for better syntax highlightning

[Sara Golemon]

On 19 September 2022 15:24:26 BST, "Olle Härstedt" <
olle.haerst...@limesurvey.org> wrote:
>Some editors can guess the domain-specific language inside heredoc, e.g.
if you do
>
>$query = <MySQL;
>
>It would be nice if this feature could be used in single lines as well:
>
>$query = <<
Good news! This feature exists and was introduced by Rasmus **checks
notes** about 25 years ago.

To use it, you'll want to hold down your shift key, then press the key just
to the left of your enter key.  This is called a "quote", and you can see
it demonstrated here around the word quote.

Hope that helps!

Seriously though, I know you're looking to help your editor find something
to syntax highlight, but this is an editor problem, not a PHP language
problem.  If your editor can detect SQL in heredoc, then it should be able
to improve and find it in interpolated strings.  Making the parser more
complex for no benefit to the actual language (some detriment, I would
argue) is not the fix here.

-Sara

P.S. - Yes, I'm assuming a US layout, you know where your quote key is.





Re: [PHP-DEV] RFC: StreamWrapper Support for glob()


2022-09-19

Thread
Sara Golemon

On Sun, Sep 18, 2022 at 5:02 PM Timmy Almroth 
wrote:
>> There's a PR linked, but we should define the actual goals/APIs etc...
>> in the RFC itself as well as the numerous edge cases
>>
> I agree. If you wanna put it in writing I can put it in the RFC. For the
> edge cases my proposal is to return that empty array like it does for any
> invalid path today. We could leave a note or tip in the documentation, but
> again then you might need to do so with scandir() and all the other
> filesystem functions.
>
> @Sara let me know if you would like to take over this RFC? You are more
> experienced than I am.
>
I don't.  I'm split too many ways atm to take on a PHP RFC.

I was using "we" in a more collective sense to mean "us as a project when
writing any RFC".  The mechanics of wiring in a method in a wrapper to be
called as a proxy from a global function isn't hard.  What's hard in this
case is defining what is expected from that function, specifically what a
typical user might expect.  One might expect glob('https://www.php.net/*')
to return all names of all root pages on the site, and perhaps all short
aliases as well (which effectively includes all functions and classes).
There's no way a StreamWrapper implementation can accomplish that in the
general case, the protocol simply doesn't support it.  But okay, we don't
implement it for http(s), but maybe we do got ftp(s), and might as well let
end users decide when they have a custom wrapper where it makes sense.
Cool.  I'm just saying write all that out and put it in the RFC.  There's
no need to know C or PHP's internal APIs to write that much.  Write out the
API from the user's point of view, what assumptions you're making about
their use cases, and what risks are presented by cases like http(s) where
we won't be able to pull off a meaningful implementation.

-Sara





Re: [PHP-DEV] RFC: StreamWrapper Support for glob()


2022-09-16

Thread
Sara Golemon

Couldn't find the original message to reply to, but #1 I'd like to see the
RFC actually fleshed out.  There's a PR linked, but we should define the
actual goals/APIs etc... in the RFC itself as well as the numerous edge
cases Christophe noted and why they aren't (or are?) concerns.

I do recall discussing this with Wez many years ago and the sharp corners
felt like a "wait until someone is asking for it" kind of situation.

-Sara





[PHP-DEV] PHP 8.0.24RC1 Ready for testing


2022-09-15

Thread
Sara Golemon

PHP 8.0.24RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pollita/

Or use the git tag: php-8.0.24RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/271140e103c334a7c6b6f33492118ece

8.0.24 should be expected in 2 weeks, i.e. on 29th September 2022.

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.24RC1.tar.gz
SHA256 hash:
f2b5a72e0500ea2e103b4d8c3241ffa174461abe0352a2cd9f99d5e3e0b7250b
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMhFMIQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvEZEACplJRmnKdnrZXyNdb7gAYwYFw1XtE5Psls
p1jFGZtC0qcHUNAIbYVwl8D62mj8V5Osd5Yoeel/u+M8e47kgCqq18bhK9IXw/qx
pgloYRT3Cwicnw0aRc4rb9762coXn8ghj1L1VY6CrIXfwv5qFbPqRrWaEr0hlPZc
rNJt6AUkAmCmXKJTvuGCs+UsbntSnFM/b38M5gck1C7Pj2aEw61QbhEMS5N83D19
VdXcOXkHQuTIU3is9pw9BWrbQDC5ddnmRm5eyGvgGN3jJWtyKKD2/8aj8eZXYUM5
7fCpyl70qjH+x06FN1cbE4Mzy5iUZfGsjbbHJaSAyEJKbGGnx+cnrmuMaQbKFg+J
PGgQiX9fDQg/3ZN+ZdsVkuArYskNRQsgJdzA9l/PQcJevdg9YFv/sIowb6My4bct
YpDqYZV66uzHvstCF668+2h1Exb/BlOxZn7e34zN7RFDfIO1/a4Rpjc/gsnxGFys
w1z4pofUUJE/ODVgNz30wZGoJg8mB9tU2azecVbarvzO3HM8ALxnPmWsdHNEy7Ov
7zwB1JUNRxgxFxjAtbIqwv3X5P6SWvGeiSAp8KssZaeg3Z7C/Rsen2Re37NdihCn
Nf3qzeLWHu5+huy3MKiO2CN1Ik/bRZl9cSQzxglMZEFFa15+no5UhAF4xc+ClsqZ
8B3EP09OvQ==
=5S5y
-END PGP SIGNATURE-

php-8.0.24RC1.tar.bz2
SHA256 hash:
f9aa29b39c6d96554df3f6241f6ced8cb39b2a5be8a83fec16ecb912a60e2671
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMhFMUQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvRND/4nOqvh2lfe/zsZv+2rpcv05+foKj0CXovU
NWXXvBR7r6Vb1O91RB3TYiynxoX3SmoIm+qaewCqRlkOLoPFzs+VB4cNKUeq7Jhx
ViZpW5QvBsYzt2aGNvkAMcJWNH7Ilu7Hf74Mw2Ebx259fMCZCqGYnuK+fEu/QnCO
B/bwCDYsOecoRvllOR/ipAWD3THMC82X1nIRmIomwdPqCvSlPps0I5KxBqA4czTH
ADIwwtPrizuXcpgqtZN7GcOSFwJ1ifEB+S8h81OdQPoYvZP6BohzdIK9EpvUBO0v
hQwWBTmfzy2p9iEjqRyE/GCUNJlkNwimN8OqLjKsFC8gri13bTbp8L9mPGT16pKj
8qbHxG5M1gJp4JCWtQidQUx4EcIUSa+mw5aECu6XZdAVqH/raUEL38Ukd0JnlqfB
kfyonvlHj024ZQHtkjI9fexNMI4aF0+SlGRnEnqsM4enTLdXiMy7I6BGaYzapJMn
3jGG5jxuT5CkjuWljSh+gomsXDdpECn6lZlNM4UBUFnyRhThrzXiLE05X6mGjya4
MvhVk2Oqad7WsDW4WBUke3w0a/lAuq8+Gz4NMqS96nx89FG9HDrmNjFSsUtpDwQw
EeeauVI0Y1excfuSTWlOW1B+FbMuJjJOiZ9FkvB8CAt/HmMZF3Yn56oBzipoupNU
MfMAf9u0ew==
=Uu+6
-END PGP SIGNATURE-

php-8.0.24RC1.tar.xz
SHA256 hash:
210932e883098e44adaa7dc21ebfea95629cdd6ed55b35aae6bf983a4e5578cf
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMhFMUQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcqbcD/0XpBY5zjMpLBGjXOnwP+D1mijnnMmJf4Dm
dZzIGJ6x+8e0kGbH3IddY6jn5SJC3HxrNmhzrhX9B4XJWBPg4Et2hxS++fZbp8q4
214N7Byye/6Qw7OLYsdM+EBadr6RY90fcKd51XkVNGl6eba8Q2poKeIeeX2IzgC0
1ZEzU7Sa8FSVHWpbhzCvJIw+3na8NCd68ujyFgfxrYl6YgbG30hYmhlPUKgMu6q1
u9RMQk6UDqeme1frYHVbF8mAn70Hb8Nxm0QJzYg+NtmIp/hwHhA0tj5jQSNt+CKJ
M9UQYQLhzFKUPN6mqqeiYNc4dclPt/HlRP1fb210N4PRGMIbPoX75p+cCJfKpVrk
6YYulGkQCHPjADS+kh/zxat6aYv9+xnSY8k1UVW/sCRa/tUVIqfENWrvMLkymxQi
SheR5YO1lHEnGYNcrgIse8ATc33Rgcn+8q+LmzsjW5F9AG1gFQegpxSxmGxU6r6N
EtX1h8Cn7l+7L7iBzgGuZXfOwFicA9whRuldt69BC+h07fUM6W3tcyRBbp3st0nV
4chZZXQtm4m6yNwvyc/BxngNunKZ1onlC4tF6K2dR+79KkJfhaqko9JnlD2YLgFq
HjaBPlt3PsBvG28iTT8QJBCnrOVkbdl6YDGcwmTtpvKiewc6vdJ6LiI7hPuoiAcM
xbA+DgWQmA==
=RlHB
-END PGP SIGNATURE-





[PHP-DEV] PHP 8.0.23 Released


2022-09-01

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.23. This is a security release.

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

For source downloads of PHP 8.0.23 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/def76050c02a560787de4678f7f04ce2

php-8.0.23.tar.gz
SHA256 hash:
a2dd50e9c4a0328d921b6bc914e8b4e6572f94f09867318f88acca5ac4fa76c7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMOABoQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcnUFD/455WisYIyIOb8bqe3HrjluS1Uqth59A550
++CDZUCcCh+G+zLNhWaEUiQwPwKn+mlprtC++gc7FoRsX/6glg+Bc++7OipZLFWu
jMmE6b1iAa56RtIQMciLCelo8QN89cBPSKDe4Wk6T7fCO9ugJXm8YylEwLaMWdsl
dysXKsB0425B/fDKXeXpgzN156ihcfFKFvO/OCi+d+J/kf0GmYX5bWBENVW3UAUP
4IXC3Xauftcit0ltKHYKYn5O1VChoV58HyQOGd7vKGpEXyn2LfMFd4eZse9FRbyf
O5J6GX9tsctm5V2peaW6m3CBCGEYC5q6AU8RC6UHgyDktk8piUUh9+CZh2fdiKqV
EHLcfY7F/ELSFZdL0l1SU2mJ65C6uBqGE2z81PNmQClpHfb50tBeY0GB570zth1i
dm+0SDDPd1ysU4rvpiOjXlRNAfpmR2Siq/US2P/MsTkfX72L/dlByw39+xr2Q8t9
8UJtXD5/eAx1HhrttmS7Z/pW397HUWyYrAgKUfdiuA1k1rnsvhz+kUR5db/59sEP
FlEHmmO+RefvdVCmINtUjM1vjyyg9dx7JIsbUiWKi5WQqNp8NK6L4VTUSoW+j3iG
Ka8Btp8ACA8/JbfmzVvwujVt3HZksQgbJEC62AAIoIML6wW0BaM6QGfNk8TQ5F/J
rzTW0jIRKw==
=RQS+
-END PGP SIGNATURE-

php-8.0.23.tar.bz2
SHA256 hash:
1412db46800a45ced377c2892ec6261b3c412f13dc133bfc998cfb2f147b40cf
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMOABoQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcs9YD/9TVXV7oYUF8eZeNI/RqyccOfbv0aiNPgo0
TqWIkPIgIIATQ4MSI/x/k86/M6mxdL2O4n786dl7+kWmo3iYrgqS9wOMTNv7g7vy
vc3pJoOSimIhx7Ktd38G8Ctn0uM8ldHmf8/CvUGSZHchn/UxyUD/P2ULQtszbnn6
zXCM3deUZDRvqHyOgLJOfsGdaQabSoQ+zO4CNHL1FXTxBC205KXMyKmPDvnspGUp
yAgVUVoG2di1XX61MQHwPuuBswlQzUYdwpSz8Dn8EiyuVQzxDEygkr0z1JHCSjZ5
e331mwI4ZNaIN6FR7sVzZ9Jnv5PNRr443baCsBWqPsLZho9hzUwUnlHB8QFrg2yH
5dqXtE0CL4LZEeDvYNo/UACbB6rUK3vCaZgNVxHdIzqP06Bm32F1ANOJUAKcYKVa
7pe2bdekil1ck+9uDg71veBg+faQhXA9ub+F+4ijZ+ngeGV1MtTjnG9G/oHbLG2k
0GJBLOlX0l+IDtQ52fm8nNHpXki845H7h5wBXLa7tuDq8QUOfiRao8YVXTLzCUSn
rm635Nsp31w37FB+85dS5UU5n7iXFh6wpyINGERHDTkQhSF3Pm06a94t5gwmfvAZ
UhWNobSLs0Yb+7GJbQYRZvYQr5X/fgut7qTY9zYQxbJE6f2tvMUkPjUkWVOQU9g+
8xB1+P82XA==
=Rhyc
-END PGP SIGNATURE-

php-8.0.23.tar.xz
SHA256 hash:
65e474b6bd8cfc9d4a8a56268a755e2f9d3e7499e1687e6401a9f2b047600f87
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmMOABoQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhciQ3D/9J8uM5DwbIifNEuzachfDtT1WiEmbfoRtx
lzs2Y5pRpaGZ3iLcXh/DVxUP4tibFy0p1+3kftpF1kE/yYapF5ExDXLdI8I3Lspd
IvabDPKNIood3SGWR3gN/sv7VqLDOfXK/7VQ3Hpqe84EzrzThNgzo1gU3Ra/tgF+
u5KGhquJZjt4SRCvEMkFmhfgWNLrpZAByUCUjFAK0l748v8TMBjR2JuBxD1ytYfb
oa4rfv++Q/qsh5Z4/4y0nk1eAIrRnqIrTPPdR8IsWqDd2QJazwOBNgwJ9JzyADEd
kTCPyORGu2x5JhUm/qgwyj66/y3+DQ+bCEObfxAAQTBYsWFBrou437MTLN0Ok6kR
UdxnaBNhDVcFBLx8oWfrvOdrmK/IYCeZLlYLW8UQFj7e3nsBJg51AanCxZHfVlpr
ZcMA7blgTlLyz53s1z6wYOUCQa5Tc9iPmEqAfFxSMx4Sr1Xcc2m29HN2X47WMIXH
9FNKwrKK0BSs32QDZW3drlKJUC5rfCWKXeMbT+APJYM9JFt1a434JTCFcT+t55Cy
2p7uTZ3E/B9fbEch3zHudYnM776pRGVMLh8BJdFYPMLPdCuL+PWEnXPr1jQ9pFoE
WDl70etjx0QJCgKyZR/+HRVfO5sBGdgAVIRENuISMuVOpR0YfjWtTB+06QnImHZu
oPb48qAPkw==
=TcWE
-END PGP SIGNATURE-





Re: [PHP-DEV] No longer allow block mode for declare(encoding)


2022-08-31

Thread
Sara Golemon

On Wed, Aug 31, 2022 at 10:43 AM Christoph M. Becker 
wrote:

> recently, there was a bug report regarding declare(encoding)[1].  I've
> checked that, and found that the current implementation of
> declare(encoding) doesn't make sense regarding "block mode", since this
> is completely ignored; instead, each (allowed) declare(encoding) works
> from where it is written till the next declare(encoding) (well, probably
> more or less).
>
> Since I consider switching the character encoding in the middle of a
> file not reasonable (and it might be hard to properly implement support
> for that), I suggest to disallow block mode for declare(encoding) as of
> PHP 8.3.  A respective PR is available[2].
>
>
I think I can imagine scenarios where switching encodings within a file
would work?  Especially for ASCII transparent encodings...  That said,
if you're currently depending on multiple encodings in a single file then
you probably deserve whatever you get.

+1

-Sara





Re: [PHP-DEV] PHP 8.2 branch cut


2022-08-29

Thread
Sara Golemon

On Wed, Aug 24, 2022 at 4:45 AM Alexandru Pătrănescu 
wrote:
> Maybe this should be clarified as the term "small self contained feature"
> is not clear.
> I mean, a lot of the new features are  self contained, depending on how
you
> view it, and some of them are also small.
> Like array_is_list could have gone into PHP 8.0.2 or 8.0.3 release and not
> wait for PHP 8.1.0 release?
> (Vote ended on 2021-01-20 and was merged on 2021-01-21)
>
> Just want to make it clear for me how the rules are understanded by
> internal devs so I know better.
> If it's not an agreement, how can we clarify them better?
>

The rules* are pretty clear.  Feature freeze means feature freeze.  If
there's a feature you want in, big or small, you get it approved by the RFC
process prior to the feature freeze date for the branch you want it on.
Period.

* Any good rule is more of a guideline.  Specific features or changes to
features CAN be considered on a case-by-case basis after the FF date.
However, the bar is set high for these exceptions. As an example, in the
8.0 release process, attributes went through a number of syntax changes
well into the beta and RC phases.  This was NOT ideal, and it was kind of a
mess, but it met RM criteria for consideration because it was an already
approved and merged new feature, and the consequence of not considering
changes to the syntax would mean that we might need to live with a hastily
chosen one forever.  Essentially, the pressure to consider it came from the
potential negative impact.  By comparison, the consequence of waiting for
the next branch on something like array_is_list() is just a little extra
time.  That may be disappointing for those wanting the feature, but that
disappointment will pass once the next branch is released, and we'll forget
the delay ever happened and move on.

To generalize:  Completely new features are unlikely to gain a feature
freeze exception, because they've waited 25 years, so they can wait 26.
Tweaks to already approved, but unreleased new features are likely to gain
an exception because the impact to the future is already there, we want
that impact to be positive.  BC breaking fixes for existing functionality
(see recent ksort() thread) are probably 50/50 depending on the fix, but as
you'll see in that thread, we reverted the "fix" on the 8.0 branch already
(fix never saw a release).

-Sara





Re: [PHP-DEV] ksort breaking change


2022-08-26

Thread
Sara Golemon

On Fri, Aug 26, 2022 at 11:53 AM Christian Schneider 
wrote:

> Am 26.08.2022 um 18:28 schrieb Sara Golemon :
> > What I can see is two noble, but conflicting ideals:
> > 1/ sort() and ksort() should be consistent about their sorting
> algorithms.
> > I think we can all agree about that in the ideal case, at least.
> > 2/ Behavior within a minor release should be self-consistent and
> > predictable.
> >
> > Given the above, my initial inclination is to err on the side of
> > conservatism for 8.0.x at the least (we're nearly at the end of our
> primary
> > bug-fix cycle anyway) by reverting the fix on our branch.
> > For 8.1, I think we have a more difficult decision to make with over a
> year
> > of bug-fix releases to go, and I might be swayed to keep the fix around
> > there.
>
> I agree with the description of the ideals but I'm not sure why you think
> the resolution should be different of 8.0 than 8.1.
>
> We already transitioned our existing code base from 8.0 to 8.1, including
> testing for changes due to the way numeric string are handled. I think it
> is reasonable to adapt it for 8.2 (where another round of breaking changes
> will have to be tested anyway) but I would not expect to having to do this
> for a bug-fix release 8.1.x.
>
> That's why I'd rather have this change postponed to 8.2 (which is not that
> far off anyway).
>
>
Honestly, I vacillated on this one for awhile, having started from a "we
should really revert on 8.1 as well".  I flipped when I decided that the
breakage potential was honestly very small.  That said, no real complaints
either way.

-Sara





[PHP-DEV] Re: ksort breaking change


2022-08-26

Thread
Sara Golemon

On Fri, Aug 26, 2022 at 7:19 AM Christoph M. Becker 
wrote:
>
> On 26.08.2022 at 05:15, Go Kudo wrote:
>
> > In the actively supported version of PHP, `ksort()` has been modified to
> > include BC Break.
> >
> > https://github.com/php/php-src/issues/9296
> >
> > This may seem like an appropriate bug fix, but it is a clear BC Break. I
> > think this change should only be introduced in PHP 8.2 and later.
>
> In this case, the functions didn't behave as documented, namely to
> conform to the general conversion rules, which had a relevant change in
> PHP 8.0.  Apparently, this case has been overlooked when the change had
> been implemented, and only been noticed recently (what still surprises
> me).  Anyway, fixing the issue now is not really introducing a BC break,
> since code relying on the previous behavior did not conform to the
> documentation.
>

What I can see is two noble, but conflicting ideals:
1/ sort() and ksort() should be consistent about their sorting algorithms.
I think we can all agree about that in the ideal case, at least.
2/ Behavior within a minor release should be self-consistent and
predictable.

Knowing the discrepancy exists in current releases of 8.0.x and 8.1.x,
we're currently in a position where ideal #2 is satisfied, but ideal #1 is
failing in a small, and subtle way.  The potential consequence of this is
sites out there where the inconsistency shows through to end users (though
I wouldn't actually expect any breakages as a result, just clowniness).

With the recently applied patch, we would resolve ideal #1, but we would do
so at the cost of ideal #2.  It's doubtful this will actually break any
code either, but potentially user-facing affects could be visible,
especially in a mixed-version environment (such as during a rolling
upgrade).

Given the above, my initial inclination is to err on the side of
conservatism for 8.0.x at the least (we're nearly at the end of our primary
bug-fix cycle anyway) by reverting the fix on our branch.
For 8.1, I think we have a more difficult decision to make with over a year
of bug-fix releases to go, and I might be swayed to keep the fix around
there.

> > Fortunately, there is not yet a release in each version that
incorporates
> > this change. I think it is possible to revert now.
>
> Well, the fix is part of the currents RCs; that doesn't make it
> impossible to revert, but RMs should have a say in that.  Thus I'm
> adding Sara and Gabriel as recepients.
>

Don't forget Ben and Patrick as well, this impacts 8.1 equally.

-Sara





Re: [PHP-DEV] What do you think CSPRNG in PHP


2022-07-25

Thread
Sara Golemon

On Mon, Jul 25, 2022 at 7:08 AM Go Kudo  wrote:
> Indeed, But ext-openssl is not always available.
> To use it in a ext-session, etc., it must be bundled reliably.
>

Which means that users can generally call `random_bytes()/random_int()` for
an always available, but maybe not most performant CSPRNG source, or if
they need those extra cycles, they can make sure OpenSSL is installed and
available and call that API instead.

Library authors can even abstract this away using function_exists() and a
graceful fallback to random_int().  I think it's okay to trust developers
to know how to program well, and to learn when they don't.

-Sara





Re: [PHP-DEV] What to do with qa.php.net?


2022-07-08

Thread
Sara Golemon

On Fri, Jul 8, 2022 at 9:48 AM Derick Rethans  wrote:
> I don't however think we should stick these QA builds in the
web-downloads Git Repository though. It is growing big enough already and
there was some earlier talk about moving them to Git LFS instead. I don't
know how feasible or proprietary that is though.
>

Oh sure, no.  We'll keep the bit of the QA version struct that points at
the downloads path (maybe making all by the userpath portion hardcoded
because the rest never changes) and construct from there.

Something like:

 [
'version' => '8.2.0beta3',
'date' => '18 Aug 2022',
'download_path' => 'https://downloads.php.net/~ramsey',
'sha256' => [
  'tar.gz' => 'deadbeefcafe',
  'tar.bz2' => '...',
  'tar.xz' => '...',
],
  // 8.1, 8.0, etc...
];

Then on php.net/downloads/testing we list the active alpha/beta/RC builds
like we have on php.net/downloads (and which we link from there).  Probably
make a nice JSON endpoint as well, because why not?

-Sara





Re: [PHP-DEV] What to do with qa.php.net?


2022-07-08

Thread
Sara Golemon

On Thu, Jul 7, 2022 at 11:54 AM Christoph M. Becker 
wrote:
> I wonder what we should do with qa.php.net.
>

I too have wondered this many a time.

> The only really relevant stuff on the Website is the listing of
> available QA releases, and the information on how to write PHPT test
> cases.  In my opinion both should be moved to somewhere else (the PHPT
> docs might go into the php-src repo, and the available QA releases could
> be listed on php.net).  Afterwards I suggest to tear down the Website.
>

100% This.  PHPT can easily go in the primary manual (it's aimed at people
writing PHP code and PHPT files are PHP code!).
The QA releases as well, it would honestly save some (small) hassle during
releases to only have to touch one repo with this information.

-Sara





Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements


2022-06-20

Thread
Sara Golemon

On Sat, Jun 18, 2022 at 9:53 PM Pierrick Charron  wrote:

> I hope you don't mind, I took some of your code from your "Enable
> strict_types checking for curl_setopt()" pull request [1] to do some test
> on introducing this but only on the OOP API. It's working very well [2].
> Can I know why this PR was closed ? Any issues ? Or was it more because it
> was too much of a change for the procedural API ?
>

 Don't mind in the slightest. :)
  Fair to assume I dropped it due to ADHD.  I have a habit of
SQUIRREL!!!

-Sara





Re: [PHP-DEV] Discussion about new Curl URL API and ext/curl improvements


2022-06-17

Thread
Sara Golemon

On Thu, Jun 16, 2022 at 2:10 AM Pierrick Charron  wrote:

> For a long time, ext/curl worked with handles as "curl resources" and
> functions mapped to the libcurl functions, but since PHP8.0 "curl
> resources" were converted to opaque classes with no methods. So my main
> goal here is to come up with a solution for the new Curl URL API, but maybe
> also to be consistent, make some changes to existing curl classes like
> `CurlHandle` to add methods and improve the current state of the extension.
>
>
This is so bizarre, I *know* I wrote an OOPified cURL extension some years
ago (called it curli), and now I can't find it anywhere.  What universe am
I even in?

Anyway, +1 on making a whole new OOPified cURL implementation.$ch =
(new CurlHandle($uri))->setOpt(Curl::OPT_METHOD, 'post')->perform();
Let it throw exceptions, do proper type checks, all the goodness.  Let the
procedural APIs behave differently than the object methods and that's okay.

cURL is a foundational extension in PHP and I respect the choices that were
made in its API design, but it's 2022, and we deserve a better ext/curl.

-Sara





Re: [PHP-DEV] Re: Adding new closing tag =?> for keeping trailing newline


2022-06-07

Thread
Sara Golemon

On Tue, Jun 7, 2022 at 10:27 AM Robert Landers 
wrote:
> FWIW, I think it makes a lot of sense, having used golang's template
> language (not everyone is generating HTML with PHP). I think you may
> just be dealing with a vocal minority and it would be worth putting to
> an actual vote. Even if it fails, we'll learn something the next time
> someone wants to change something like this.
>

While my gut response for the new end tag is in the "no" column, I do
wonder if we can accommodate "non-html" scenarios in a broader (maybe more
palatable?) way by assuming that if you want the newline to be respected on
one line, you probably want it that way for the whole file.






[PHP-DEV] PHP 8.0.20RC1 Ready for testing


2022-05-26

Thread
Sara Golemon

PHP 8.0.20RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pollita/

Or use the git tag: php-8.0.20RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/efa581558c226f7de4f45d85352e7588

8.0.20 should be expected in 2 weeks, i.e. on 9th June 2022.

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.20RC1.tar.gz
SHA256 hash:
c2e1dc4f0162700c2dc75616c47df28087bfca1d10d66ef97a7b75b15330383e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmKNKF4QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcpyHD/4vaMLLMH3ab1aJ+5RLsNtDpgA0IjmKLIAB
zlpEuteqypqLKq68cQGO6mQZoOYelEIDx80GHCFT7mSBtSCU30ZuViatWZRkTc6i
vt80pyHILy694BepRn77AQOu/BpcN+8PuPnrxLxhmTWdI9qMgyA5OWjoaEL5cS9W
cTHddGrxukuPaKqrgV0+o3XtIMGJw5joTBW8mnq75ncQDSsk17JnlBdPtfyxloFG
/RCbDlmuUzvzDuL65adpWInWWwN/jbuddrcBnvhg1za7+cR5AvsRPjYE5bCQMgQV
AZ5J3e7S1Z2KDW4Yy9sTazOuYKC0PJDRQP4Q2DeS4Pcxk6bHpFY8nFvQd/fGlAh4
OKBR1sunjX5tTBAP1gaMg7ES24HO9VgnuDILB6lrPCCO5LVIEDgErwdQswPV+sqM
016AXyq6pFu5LXEMxt6nmIsveP0j3zXWPY2OvAEK2bUtHN194WyRqUCMzwWp9hSZ
4AbCale/DGO4jO9oCUVVVXBVIcj9/V03ajRTGv4FSP12Ia2dOgtIE+Rjl5U9iBti
c+DA0UA5MdCv8kPlfJUIiAp1Oe2u9G1ILhelFA3KVZh97FYxigmZXozQnAZWI8Pr
Igp6SX0CleCSu3GCRxOjgIdPTYIdQQNvNUjQzVJFT9edhA1km69NI2NBsKcHPaZ8
qypgnODfIg==
=zglc
-END PGP SIGNATURE-

php-8.0.20RC1.tar.bz2
SHA256 hash:
4380b18ae67e064cd015cf7e876cf3cb844eb0e9ae68eb715ddc178b54283c82
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmKNKGEQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckn3EACtYxMT2y3A/5jXfmjQg3gsBbjWy4nsMY1R
vR3fb4ZmDyROMpcdJdlU5TLqV1n1YJzcNapoSA9UxHGXrp2eofVHFm4lkzh3mLuP
UlvH0itIjEJE7EzEa5qrgqhhqv2nt9Py2LSL47gEwpvX7sxW92DWEpaH7kqpH25U
Wpii2CcWm9BZmNdMhCrnsu+53mwzQfow6eomzJNkeNtdA3B6yOy5ZQE1UNW/1acf
7FNOygmrgWIxu+P/F4UdwDtMvqkoJTD4bbQUc7+9nsare/Vm/oohWo0DMYNpZnyq
ghDRSbAhlvNqiZu9fVK93EoKZAEAPVYoCY//oRceoXNh9vm7Crq7Gywc9ZtUxUzU
Pm4HHKJbAmv5aI6aPwXvqJgpz6WqOWYDg4mo1nHjs0mfE0qtXWJ/g+Xu0Q5hsvZY
LnntqBTZ2V0V8Ons2aAHiqbDKY+MzyVVdIj0lYVdB9a3e1id45lSXkcPku3H3XzC
TXcfHQSAU5Yliuy9FC89FrGEgNn1k54aIstHdcQIpL9z8l5GSu8dCIXYTTjijx5l
fMyiVNF0+ETU3vjnoITcP/C2q3aKlk85Dx68EOBUkmsyR/Bfjsk/5YwQw/xRQVZN
YgekTLMJaHhX/Oux4Uj773B8k6oHx07NGC1aZ9BrXiQhJ1R1qrpsVREDXpZ5glav
A2aJK5/uhg==
=aOV1
-END PGP SIGNATURE-

php-8.0.20RC1.tar.xz
SHA256 hash:
f6cdb3f90838d0a0215f92e3ce41c00934f36e9c6a3ab05491168ba5c5b6c8b4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmKNKGIQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvH3D/wLdAuYArF+rTxHkQ43Ts1EU1TFJz1x9Lus
d2s5+E0ZSFNZiwlltd2KqI8tYx2f4qrxdesbmF9V4AVL4nM2yDgi6psNfhmnMjac
JLjACsHqOmXgbaW4a4SuoXo1oE8VkWFrI7sFdbI3ZqyduwrOzukJIzAKQP4RW5s1
o0WrIGLkPBN4faJ+ATVfmL/r8DBDT8Y0Fv9/keKdSqE009IBucFBIvIv13wY4RoL
EBjUdj8O2XIT7dgW7XIcLY4Om9f6YqK9Qa40LKk9YLJXu/qm9zPQZ6fxR51m9ouE
r9cwPL8s/QAU58Csfc5wlR6Rps1mGOyMMfyAncNjN6FoG2ZXXj5tM88B56YUHX0t
rrmI9Q0jSkv+dK77ZJNQaD96p8fqevE4sWiTdJCIO3NzQGquklDmaY2NvkXeqYBH
Eu4YT1nPdfTIz5FTuPM7CHQFtid2v8lTFExFCtRwd4adph4AyvQQjjDbVIWjS+9f
HsXFMVGIQrCbZKs64mDyaQcKQOwoN1apyhGVcmkhZWNEG9Zj6s3cRPATFojKh/Uv
r1gkD38qxBs1puhtQbKUSauF8S3GaU7APnlrFJXUF6HntW5zOA2XZUz6jRmlOiMh
FeAYx/LoSTQx7Bg4qahsBykTwQs0F41Ny3l5uEK4CctCPzvIN3Np3VDLvylQYgsY
QhSisPloXQ==
=77/O
-END PGP SIGNATURE-





[PHP-DEV] PHP 8.0.18 Released


2022-04-14

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.18. This is a security release.

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

For source downloads of PHP 8.0.18 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/f835da768bcab8e2fb025a24fe045195

php-8.0.18.tar.gz
SHA256 hash:
cd980f5a2f422362f8c52d314ed25140c6f472877c5442c4f3304205f54e192a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmJWOf4QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgJwEADVrZudi75SwRcbMsNBADrpmvsj9Z35HEGZ
ARg/jF24tR1HMTzvzKf6+ujfKBTtUL5QPI/K939DrarDmwTSHzcDaA1KNL+q87no
dhfTnyajnGBK8LIETCTY7wwsXgLGpNcRzfIvuLRbEk3k96gcRaXS6ic6NazKxldW
SJe8VjuIj8RqgwAAWbby5t7zB4mdw26WZZ860W3JXq9DeXwxV0f0Jz3UD/ZliVQr
Dbw/w3UwjOgaLEvK1QxK6T8eoZBZQXPwu6ft8tl/dLrs2slgs2qpuRROAZopZlMl
SXaB9mcxMWdWw4TRiTrsPeUxQTdw+UGspdJ3rWCFxOAZTALJ5ZXBdfcdT2kygpBV
2ldzsuNeOXCH+TDlvJYsfXrqIQCMOQOpCojovhKCPobhETU7jtvNEQ8PdV/p8Bqf
7t20lja/EzbC0ubzeJdqObFFch4BaO06Gmfoe2R9/IyYU6yfDTvOhkrU3TMoQFvk
H3DauvDcKhdrVELq1/JPm5TSkOoAhpuvUHxXja45olAmTz6Ccr45sAHDkewaKYGH
Imd9uxw67cUHRzPy2znaFt5+j5dasCWUGYWnQ2vj44PhM5L0zn6u64rdkgTfIBL7
77SCbPNXOf1Hf/N7yIkHMNWVPKOXt2g0AgSgRSLxMJ4l2Ij3o+OBu5ZmONabXTAP
r4vrEkIDHw==
=WksU
-END PGP SIGNATURE-

php-8.0.18.tar.bz2
SHA256 hash:
826ee34881a1c349678d4f7cc55ff9141fa1411344e4bb8f95d0f9223bceb55a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmJWOf8QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcuA8D/9GmHAvbkcq5maH4PeMVfUU9u2zPkwbFsFc
VpJ0WRoGMDKuJNmBgwEjb5kWYVIEvNtYNwp6bnoB8FaC15JXNTKiaUPULZ8UEFgY
sCH4F2SOSAKMqspp0SyhPZjO1SGvRNFojE5nH1YoJ+hEF3C45ImmlzwhpncH9s66
Ja9SoAF7FTKJkJbauwunsUR3Kb1lGKdvbaqHLOdgpnAohmMqdKm4hBvMzPYxYsQd
ytpDihWF38FqXYabj6acSNpctvU3JHUTZorO96Az8EjR6ykil2HMrPXbeHdFmnL7
4uluZ6TbeGlge2ujdhrKZl0K6Sl8uOQL6W1rauw47ZvYnzHLfNOL0TN/RyebyL96
diS72um43+5BPbKCEl2jekRofYYzcWDBQcU25wFpxfJcpELNCzK1/4IGm5+3SvNB
4uzaJ8zBK3JjcoQmPDDyKptl5qLaP1iM52hGwoCBAk0DSzUFt018kR7k6GGFrAYn
1DIvRifNcFA3+xJP1AH6znxdC3gPpxOvJrjEoTD3AGnqPM9gGg1iMFUt2/6p59tI
E2RMMy+fC0gZY9aOUDBibSlJ3lscslWRzykXZMhbZiuVX71DDfB9G7a7/ZLG0lWG
OysK2Ur5lBFa9axY191UXyrWE+0KFJaR++RHQhYsP0CSTmRmJMM+BERrYxPHlHvd
RruMeN0iQA==
=LnNe
-END PGP SIGNATURE-

php-8.0.18.tar.xz
SHA256 hash:
db161652cacae4b31c347fbf2e17b80656473cb365f2bb3460c4552f5647e2e7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmJWOf8QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhct5wD/9SayczkCKvLJiyob5Bv2HlmWO2+NMIHCBr
vlJycmTGKdaGazwLxuCVhzGViOT+XXiazcGLnhzO02Hn0LHNY9kCuFARkejNAYox
J1LIhrPd1VH0NsBhqedZZNEnLzf3KiWAniol8iEcNS0QJgjU2mrNHfMIFSlhR+eO
sw8c9Xh1+vSikIFGmTmTr0eegVmyzxMioVYEOY29/ZcKRxDFdxNDxhokn2l3uN1G
17eNvCSOs6fiFHW7n/jyOOc0Xz1MLTtp/J2lteW+ccqoAJ/4mj2w3WIdfPvxWWdz
wSvjzEbv71rZyJxE7DHea395LXXSjmzrYJ4gbMbq4kD+8Gf+AN8mlCdfQ2aFOJuD
k8HuSWRvUESPvrRgvoBPWPLiT0T6QmlUQ4WxXX7UgICqNKI2IdqzputCIAuulPY2
TLTy7UH6XE07h1S2MyXwmWzExbx1DIn7b3Gue2Zi89y270ZSZIxgR1xmERrsQ52Y
FsjMGTzsSu53FyGnDKmzCOhIrXWkyL52QByGxVYNgNc7YPO1EztUn2fXd/hOukR2
I9/AE0UAaFLtsXIqrq86QXaH5DfFBksTuQlbw0m45/KXWfkPeCO29Ido3yVH/nn8
4SPA1uxd5DqetC0f7xElSUyCn8YEOAQ2vi6TopNsKmk+Mig61mSE4trDiTp4zeqU
M1OucrCw/Q==
=9VB3
-END PGP SIGNATURE-





Re: [PHP-DEV] [RFC] Add true as type


2022-04-11

Thread
Sara Golemon

On Mon, Apr 11, 2022 at 8:59 AM Tim Düsterhus  wrote:
> For `true` the story is different, as this type is an entirely new type
> available to userland and by the same argument one could have literal
> strings or literal integers as distinct types as well. I wouldn't object
> to that per se (and there's precedent in TypeScript), but there could be
> a clearer plan for the type system as a whole, instead of adding types
> piecemeal.
>

^This. The bit about making a plan, I mean.  A slow erosion of what it
means to be a type might be the easier pill to swallow, but it results in
more chaos overall in the type system.  I'd like to see someone (literally
anyone) take the time to sketch out a more complete picture for the type
system.  We can implement it in pieces and parts, but we should have a goal
in mind for where we want to land.

Using this RFC as an example, it naturally leads into the question of value
types (which is what `true` really is, a bool with a value of true), so why
can't we say this method must return the number 42 or a string containing
'pamplemousse' ?  A roadmap would help us understand what those kinds of
value types (in an unbounded type like string or a large bounded type like
int) compared to the tight bounded type of bool.

And yes.  Generics.   We can't talk about the type system without the
subject of generics being extremely relevant.  Ignoring them because it's
complicated is just kicking the can down the road.

All that having been said, sure. I don't mind adding true for completeness,
because it's fairly obvious and the scope of bool is fairly small, but I
would really encourage anyone to step up and plan out a wider reaching goal
for the type system.

-Sara





Re: [PHP-DEV] Re: Add leading backslash to enum and class names in var_export


2022-03-31

Thread
Sara Golemon



> On Mar 31, 2022, at 11:03, Christoph M. Becker  wrote:
> 
> On 31.03.2022 at 17:45, Ilija Tovilo wrote:
> 
>> We've had two bug reports for var_export not working for enums. The
>> reason for that is that var_export does not add a leading backslash to
>> names of enums. This will cause them to be resolved as
>> `\CurrentNamespace\EnumNamespace\EnumName` instead of just
>> `\EnumNamespace\EnumName`.
>> 
>> enum A {
>>case B;
>> }
>> 
>> echo var_export(A::B, true), "\n";
>>> A::B
>> 
>> 
>> This is a problem for things like Doctrines ProxyGenerator that embeds
>> the result of var_export in classes with namespaces
>> (https://github.com/doctrine/common/pull/955). The Doctrine team
>> resolved this by adding a `use` of the enum at the top of the file but
>> that really shouldn't be necessary.
>> 
>> The same issue already exists for classes.
>> 
>> class C {}
>> 
>> echo var_export(new C(), true), "\n";
>>> C::__set_state(array(
>>> ))
>> 
>> https://bugs.php.net/bug.php?id=64554
>> 
>> Marco Pivetta created a PR that adds leading backslash to all class or
>> enum names of var_export. Adding a backslash will make the code work
>> both inside or outside namespaces.
>> https://github.com/php/php-src/pull/8233
>> 
>> To avoid disruption, I'm proposing to merge this into PHP 8.2 only.
>> Unless anybody has any objections to this change I will merge it in a
>> few weeks.
> 
> It might be worthwhile to point out that this issue already came up
> years ago, and after some discussion[1] the idea was rejected back then.
> 
> That said, I'm not against changing this now, but would not want to do
> that for any of the stable PHP versions.  Targeting PHP 8.2 is fine for me.
> 
> [1] 
> 
> --
> Christoph M. Becker
> 
> -- 
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
> 

Look, just re-enable spacebar overheating, my workflow works for me.

j/k -  I'd vote in favor of this.  There may well be people relying on it in 
some way, but it's broken IMO.

FTR; I'd also vote in favor of a ReflectionVariable kind of interface to allow 
wider control over the output.

-Sara

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






Re: [PHP-DEV] Typed constants revisited


2022-03-24

Thread
Sara Golemon

On Thu, Mar 24, 2022 at 10:20 AM Pierre  wrote:

>
> That was exactly my point: the type could simply implicitely be the one
> of the original value.
>
>
That works when the initial value is a literal, but what about when it's
another cost?

class Foo {
  const BAR = Baz::BAR;
  const BLING = MY_QUX;
}

What type are Foo::BAR and Foo::BLING?  Suddenly these constants have
dependent type and resolving it becomes less trivial.

Also, what happens when this code is originally written when MY_QUX is a
string, but then gets redefined (because it lives in another library we
don't control).

Allowing the author to put an explicit type removes all that uncertainty.

-Sara





Re: [PHP-DEV] Discussion: String streams


2022-03-23

Thread
Sara Golemon

On Tue, Mar 22, 2022 at 7:21 PM Larry Garfield 
wrote:
> Are we talking about *arbitrary* user-space operator overloading?
> Because a very specific, non-arbitrary, well-designed operator
> overloading RFC was just rejected.
>

Yup. This was pointed out to me in r11, I guess I must have missed that
vote when it happened.  Not even hitting 50% is as telling as it needs to
be.

> Personally I'd settle for a bind operator, comparison operators,
> and some built-ins to use those for a new stream API bootstrap.
>

Yeah, streams need real love, and I hope someone with more investment in
the subject takes on the work.

-Sara





Re: [PHP-DEV] Discussion: String streams


2022-03-22

Thread
Sara Golemon

On Tue, Mar 22, 2022 at 10:28 AM Pierre  wrote:

> Le 22/03/2022 à 16:14, Sara Golemon a écrit :
> > Who's just a hard-nope on userspace operator overloading?  If your
> reasons
> > go beyond foot-gun (and that is a valid reason), could you share what
> those
> > reasons are?
> >
>
> I am a not so hard-nope against userland operator overloading because
> it's magic. My day job is 20% writing code, 30% speaking with clients,
> and 50% reading and using community code. Userland operators are not as
> explicit as verbose method calls; and you can't ctrl-space an operator
> in any existing IDE, it's not obvious at what they does when you read
> code using them in most cases, and beyond that, in order to use them,
> you have to read an external documentation.


Yup. I generally file this all under the 'foot-gun' objection, because at
the end of day if you've made an overload interface that makes your code
hard to read and reason about, then you *have* foot-gunned yourself.  Not
dismissing it at all, because the struggle IS real.



> And in the end, operators are just sugar for method calls. I don't
> dislike writing $c = $a->plus($b) instead of $c = $a + $b, I even found
> that there's some kind of elegance behind writing stuff explicitly.
> There's no feature in the world that would be blocked by the lack of
> operator overloading.
>
>
100% not going to argue with you on the accuracy of that statement.  Of
course, something being sugar doesn't mean it's not sweet. ;)

-Sara





Re: [PHP-DEV] Discussion: String streams


2022-03-22

Thread
Sara Golemon

On Tue, Mar 22, 2022 at 10:31 AM Christian Schneider 
wrote:

> Am 22.03.2022 um 16:14 schrieb Sara Golemon :
> > So while I said I wanted to avoid the firestorm suggesting userspace
> > overloading would bring, maybe that's the question to ask:
> >
> > Who's just a hard-nope on userspace operator overloading?  If your
> reasons
> > go beyond foot-gun (and that is a valid reason), could you share what
> those
> > reasons are?
>
>
> An obvious one could be complexity.
>
> In the discussion about warning in conjunction with type juggling it was
> mentioned that this leads to increased complexity in the PHP core. While my
> knowledge of the engine is too superficial to really know I'd assume that
> generic operator overload could lead to quite some additional complexity
> and/or overhead.
>
>
I'm not terribly worried about complexity since operator overloading
*already* exists in the engine.  The only thing we don't have is a little
bit of glue to map these out to method calls.

This would be best served by actually writing up an implementation, which I
may do yet, but at the moment, I'm just gathering opinions.

-Sara





Re: [PHP-DEV] Discussion: String streams


2022-03-22

Thread
Sara Golemon

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

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

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

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

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

-Sara





Re: [PHP-DEV] [RFC] Disjunctive Normal Form Types


2022-03-21

Thread
Sara Golemon

On Sat, Mar 19, 2022 at 12:15 PM Anton Smirnov  wrote:

> 1. I think that syntax would be cleaner without the parentheses
>
>
No. https://c.tenor.com/zM15ZrNYp0QM/no-michael-scott.gif

Grouping is never cleaner without parenthesis than it is with them.

The actual proposal? Yes.  DNF types as the next step in complex type
expressions.

-Sara





[PHP-DEV] Discussion: String streams


2022-03-21

Thread
Sara Golemon

TL;DR - Yeah, PHP, but what if C++?  Feel free to tell me I'm wrong and
should feel bad.  THIS IS ONLY IDLE MUSINGS.

I was reading the arbitrary string interpolation thread (which I have mixed
feelings on, but am generally okay with), and it got me thinking
about motivations for it and other ways we might address that.

I spend most of my time in C++ these days and that's going to show in this
proposal, and the answer is probably "PHP isn't C++" and that's fine, but I
want you to read to the end, because XSS is perennially on my mind and this
might be one extra tool, maybe.

PHP internal classes have the ability to handle operator overloads, and one
use for overloads I quite like from C++ is streaming interfaces.  Imagine
the following:

// Don't get hung up on the name, we're a long way from bikeshedding yet.
$foo = (new \ostringstream) << "Your query returned " << $result->count()
<< " rows.  The first row has ID: " >> $result->peekRow()['id'];

At each << operator, the RHS is "shifted" into the string builder, and the
object instance is returned.  At the end $foo, is still that object, but
when it's echoed or cast to string it becomes the entire combined string.
As implementation details, we could keep the string as a list of segments
or materialize completely, that could also be optimized to not materialize
if we're in an output context since the intermediate complete string is
unnecessary.  Don't worry about this for now though.

That by itself is... curious as an option, but not terribly interesting as
we DO have proper interpolation and it works just fine, right?

The reason I'm bothering to introduce this is that we could also build
contextual awareness into this.  During instantiation we could identify the
context like:

$forOuput = new \ostringstream\html << "You entered: " <<
$_POST['textarea'];
$forURIs = new \stringstream\uri << BASE_URI << '?''
foreach ($_GET as $k => $v) {
  $forURIs << $k '=' $v << '&';
}

These specializations could perform automatic sanitization during the
materialization phase, this could even be customizable:

$custom = new \ostringstream\user( landonize(...) );

We wouldn't be giving arbitrary operator overloading to the user, only
arbitrary sanitization.

Alternatively (or in addition), the point of materialization could be where
we make this decision:

echo $stream->html();

--

I'd build this in userspace, but of course we don't have operator
overloading, so the API would be a somewhat uglier function call:

$stream->append("This feels ")->append(FEELING::Sad);

Maybe the right answer is open the door on user-defined operator overloads,
but my flame retardant suit is in the shop and I don't really need to open
that mixed metaphor.

-Sara





Re: [PHP-DEV] [VOTE] Undefined Variable Error Promotion


2022-03-15

Thread
Sara Golemon

On Tue, Mar 15, 2022 at 2:08 PM Miguel Rosales 
wrote:
> > The RFC states:
> >
> > | If the code does not currently emit a “Warning: Undefined variable
> > | $varname” then it is out of scope for this RFC. This RFC does NOT
> > | apply to array indexes.
> >
> > That explicitly excludes undefined array indexes, and apparently also
> > excludes undefined properties (which raise "Warning: Undefined
property:")
> >
> AFAIU error promotion for undefined properties has already been covered
> by the Deprecate Dynamic Properties RFC
> , which will
> start throwing errors in 9.0.
>

What I'm hearing is that we also need an RFC for promoting 'Undefined
index...' warnings to Errors as well.

-Sara





[PHP-DEV] PHP 8.0.16 Released


2022-02-17

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.16. This is a security release.

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

For source downloads of PHP 8.0.16 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/6fa7778121674f2e123f5ca91de4c224

php-8.0.16.tar.gz
SHA256 hash:
ce0ea32ff9c5af18cfb70197b40caf55824400dc8d5b4258a783ec9168baa5b1
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctY3D/4hLEwof2fE2xCslSbREGRtl7FpAW0m3GUw
w7E74m9Z+nqsWxxKS4tIXuFWxUddlekegs8VSyxUQel57H6Fq1FNrDNfI8CcDScC
zH0JBvY3CTQQCGYGg2xB6R6M/FSEFhjqbSgLmHPoib+m9OSAdxI452YnrBPODFdj
GriosG2VhVKt0+SjSL594NA7UhP0g5sV52aKICvoa0800ikHNHH7+NDxkd023T+j
cTWjwDFm2meQz5qTwUA8CCWg5F3d2qTq47//Q7ILf6PJ1Pw8VFoTKGLMTmaXv2BP
XUXcLqLqELs91p7V4Sj60go5jt27gncVR6cwirnTPA5C6hjLANFCgpAK+M132NaD
ANzt7Ff6WyER4FjenpUYqhGY5I8XVSrmpvXTAaV8ZZFLcbC0uS1qOQT7j9CKL6Q6
1EFZu3ojPuYXgWJyrHxetVbYyCzVMapEdSkaTIebDt6v22JRbesQEERY9xaaspBT
tERvCHawaOSDrxk/mFyTB3bWnTPTyR6eRm4wwD83sLa9L8JFlTF3OQnAZ4blQC+1
h1O+wX3sj+ZtweOT73KoiurExG2pclsu4UERCDvWKBZMWkQTaBsMf7q1GCu8va7x
3UQftW1dHuWIiYgu33XsvXYjGX/ZlB6Fq06W2p/PGOKgiOlY3JYRPjc/v42v6Umo
z8WZK8ahbg==
=obDa
-END PGP SIGNATURE-

php-8.0.16.tar.bz2
SHA256 hash:
f49f8181ee29463a0d23a0c65969e92d58fee8ac564df917cff58e48d65e1849
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchSPD/4p8Kcv9yx0Zah8X0h+U+OtVCAIZytBEQdP
IdqERLF27zNY/H1g35jSzUwZfoxAjj/aCoB6J5JlyiPLynFvRvHSUCqjBLz1ZUR2
yLlvbNEZk3vcJr6eIcYHuDaPMAKhH3mVJz9NcHBLRQ9D1cf5CHVmWSe6aPpAebiz
/9261NXDV0LeDGvRcsCltvTB2Ogao+wYTw3FR/pzWto6khVqTND9cXgbipLFVCfb
fJe9fIiWd3lxl9joYhBTjtczSX+EB02vy32UnGOnaScSjPQvt5nMEq/c7gNDPWEu
b/180rgvjwtGP7Me1sKxt8tIziSsl1F7E/yzHfcxxbqH+6KYFxTWpugI2t8+8gl3
LfNwfDctEPv115jGuhgT2Ax6tVh91FIUZgUZ5wo52DVveHazGJcypgUnwsdm9dtU
TSjg8TEzTYdc9XmFBmEVesvwDh7R3poL1FIMu2Des67tCesb2OddZm50FwaqBUPt
LpAaBFhnDIuUPtKwXrd6Ry7RooqQRP6p4R+ufI+oluXJe67MquZp89NHny7Vslb1
PBeIZFo/ha25Ewz63cFRhDjtxkkEuSxJp3jxuD59E61ExpfAJYsf0QchTOzeyHHS
UFpoNGDs4/zYx9Etd+1xKZrPaetyPU/JmJO6f0cHs3fKgnkbK/CXMGrWkBYOJRc3
/TKzrIHzTA==
=P3Cf
-END PGP SIGNATURE-

php-8.0.16.tar.xz
SHA256 hash:
f27a2f25259e8c51e42dfd74e24a546ee521438ad7d9f6c6e794aa91f38bab0a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmIMHSUQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcsyED/9AmWycfv8b6e8CA7w68EMDpo2tRQD2Ox8+
1Lp//0EQLsUakhT+GDl64v/I1viwul9+YeFFWugI85y7wElBYtPqiQdCEBDuAmTf
MKYnCnVGdarBXZecm6q+neKVC3aSJtVriqqX1TM/DoAa8mFSOBl+KfA2vOFv8M8m
d8lhyL2O55eFAO6IhnaN/K/BuljOBUP05gsGRSGs+cyAVQMlOWZicvVh0UCR4lIe
oDqXk5N3P5NoIUC7SZMRLj7tTfTM1SL460HKuO228rgl52zN5yml4zmpsVAyGTXV
hg0dKcSZV3LBvOlQ3bjNOTRRnfJaDmbOWYUFok5tQOjJIeRAAhVwXXFSoSTOPJG7
HsoEJ7zJ9X0NaQDoGXJ23mVr+lgJE/CfOnB4UQiRSU9yUNzNW4mKQ+fKuiOMHp/B
KomgkUmffG06BmWD2o1bFaIhtITK3W4DNCeZ9m6oat7GcjhgwUxTUVy+3XiSpnc5
Xhc68IOIQBqE+zQpA6tQagEpkOiwywKHm3XarESrXGJL3p24bQTP/NFwh0oW24qQ
EtqPXgSh45ZvKCQQShRLQ5zOTD6MYMvKswE9kxfQxBX31mOHRFRK88Kr0LabBczR
NYi2/u7OXHje/OpoExdfRlPbA16+fEDk7a7vYThDDaQcgixyCnYOpJppRw2n1vtk
FNklJqKgGQ==
=GwT8
-END PGP SIGNATURE-





Re: [PHP-DEV] Multibyte strings


2022-02-11

Thread
Sara Golemon

On Fri, Feb 11, 2022 at 3:14 AM Rowan Tommins 
wrote:

> There's also I think a myth in people's minds that something like
> "string length" has a single meaning, and PHP gets it "wrong" for
> multibyte strings;
>

This++.

 Unicode is not a static standard definition of all characters.  New emoji
are being added to the specification daily and while a glyph like  might
look like a single "character" to a set of human eyes, and indeed in
Unicode 6.0 is a single codepoint (U+1F46A), prior to Unicode 6.0 (and
still FTR) it was still expressible using Zero Width Joining as five
separate code points: [MAN][WZJ][WOMAN][WZJ][BOY] which mb_strlen() will
tell you is five "characters" long, despite being visible as a single
grapheme.  Okay, so we look at the ICU grapheme functions, but depending on
what version of the Unicode database is installed, that answer may be five
or one.

In short: Language is complicated and there's not a one-size-fits-all
solution.

-Sara





Re: [PHP-DEV] Multibyte strings


2022-02-11

Thread
Sara Golemon

On Fri, Feb 11, 2022 at 12:26 AM Michał  wrote:

> It's a known fact that nowadays most websites use at least UTF-8
> encoding. Unfortunately PHP itself has stopped a bit in the previous
> century. Is there any reason why the mbstring extension cannot be
> introduced to core in the next major version (maybe preceded with a
> deprecation message like it was with the mysql extension in v5)? All
> functions from the standard library would become aliases for multibyte
> equivalents.
>
>
Only that it would break a great number of assumptions if strlen("é") after
decades of returning 2 suddenly returned 1.  That's a trite example, but
it's the sort of deep rabbit hole that emerges when you start to really
examine the problem in depth.

Perhaps you're unfamiliar with the work that went into PHP 6. It turns out
that building unicode into the heart of PHP isn't a new idea that you've
just had, it's something which we invested a great deal of effort into and
the discovery we made along the way is it's a great deal of
complication and computational overhead for dubious benefit.  Turns out
that yes, developers do use UTF-8 almost exclusively and they know exactly
when to use multi-byte aware functions and when octet focused functions
make more sense.  The landscape is covered in abstractions to make this
simple and automatic, and suddenly changing the foundation would do more
harm than good both in terms of developer productivity and performance.

-Sara





[PHP-DEV] PHP 8.0.16RC1 Ready for testing


2022-02-03

Thread
Sara Golemon

PHP 8.0.16RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pollita/

Or use the git tag: php-8.0.16RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/30338f5a826768c9ea39a4020ee2da8e

8.0.16 should be expected in 2 weeks, i.e. on 17th February 2022.

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.16RC1.tar.gz
SHA256 hash:
b54f418f4c28e27b4c41b3f490c945c79266c2fd014060b59625c2acd4869a59
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmH7FQ0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchWbD/40u6MoYzAJafrAq+afb6va2D4B7qQc/A/7
egFG0ppI/xS6Y1BavixAFvuSEZsBriVSphS9VcYNZhZQd0NIK5beaBLWgiEOYGS/
lpHDf9jLc8aQu6SmGCvfVmLRRpEfGkoY9ejtWUz7Sy2eDbp3SvPeCqPnNSuAEAP4
0qeBdt5bZqSDIEQUVRcF8VUcexy5Zk+3mpGtswC99qQiT6yBItmSZzwJKdipFFeo
gZQmdtapM1Dvw1i2UZKzI3FF1M9H2JZZAo5//LzDbJB5IvVuBLJ3qqi0s96nv9fT
UzQxrIgFpOnvNL4TdQjAdWrEvJrVLgYx0CzqIZVVfXO7Wyqe7lrA0iODQo9uSNW3
GZy8MnykzIz5f40h73SjDsLFapgcwhn3XtRnXv6p2tFgYc38DPoDzpPLkzZNqrXr
sYDbLSyWhwpcuhnk3sQToxGA8u+Ug7yD1qvxBlVvmqFWn+N+H0EAfAMzHldFuIhh
n7/wqKJXYKkLmbZT5QqlbSUgFJxtMJk30Z/STJZiz9Zhl+jBYV3fduyzGefdw/wy
xlV5SSvlylLcex/OSLCDH5JUzhlLhFXnNwRZOIy7VT7sbd8h9vFzXz/0OvkA+0ao
CNuO3cIT4ABtIVhip8Evzm70w2UMNKJeyL+S4mq3Fx7I1nynsl8pjjlgb876R8E8
yA2UzDFirw==
=vgRT
-END PGP SIGNATURE-

php-8.0.16RC1.tar.bz2
SHA256 hash:
4ec60da0f80441e3d9358a1deb7e613cc483347ecd873d1698819d9bb53719d0
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmH7FRAQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctjuEACiUKBld6Ua2mz+Ek1U39OBRhIl6ucJxGtK
v8med4vAC1/ltUuClFP96IlsjIT3McWYRE8AiG9XSG3DFieRYAiX+SEdMKmZCjBl
HNb+M2O/yoLa/MaihIFecfYo+cATSp7rI4kBlR2nTatBh/7O8NcVoWeYtSw5N29L
IIUanYZO/q0aAxSw68/aVPUG3RkYq0L0Yl3H8zWvatnxjCCL3J6JYTNLdWPXMxhq
gShq2K/961wggBmyciSfOEqk1a+BRiudOw6MDFdUEHPu3YWV+XaE5uG2eYF1Shi2
9A+wPyvoTu11q/7HHJ8KWbNBeiczvYKtONqE5eF76YuRUnlNEAXgQJ2XZSEIEPqF
9bz4/H4KIUBtJs1WT+krjxLfCl9TPOTXx5AMmbwPNUeXBUbE6H4676n8tbp52WLe
zBc1I81wt+5syILe33rZBD5z2/VBjrvtZW6F4xSvL1utBJWKeq3PfaOyj6fErymD
yOzREyhZ0/4+6oqBjrg5Am1oDxbRivBoVL3iv67Iflb1dhsGLlqJDKT9dSKcYwvz
24cuTnZ65exomP9gxUer7JtKEGFdeHHqS0HrUgu8LWqws4tFlI2hiLsEF2PqxQem
lqKUsVHyBkBHea4sF9GgWVfCZI2oxzciZpgpS9NqNqxQe1lpn/0MAbxXN3+nGqYw
yDa6lBC8bw==
=zVlv
-END PGP SIGNATURE-

php-8.0.16RC1.tar.xz
SHA256 hash:
14cb18fd8434a6d9ee6c00b74ad9d2b80a16fa16c9f67914260a05f9b7d0a31e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmH7FRAQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctL2EAC55q/zxoSFIKCKGWRnGTYQcUfVFOfF7mg8
86+9e7ckue1lgJbK/2JyYcelxoINHnE9J+Cf2jDxk2fDqPjXE223Q4AsQQ2rVrUP
Dir1Lfy1PU1dKT6Q/t0bES5M6/J6Kg8tBX5loOhSbaohn5QXW6yNSnLLxB2xnJMt
J34IPuePyrLP10++nCM5eM8wDikrJHDoV/oq8KGkmPTgyqU2Xh8EDKkQjwlrDMAH
KLPyL8kpNEdTCMm3d+4Z47vQgVDL7I8FqpIsuF4lCj6oBG+tAhsAcpACaxCPbGsT
mBsl8BBvkJe4r9OJLP48JHiyJifmQgZeNmomJQDq5MXfVm6TrufJsOWejCKWCvD/
SOtLzu9zebGQjtjaQgSUONzgOjurYgIdI7vYewAgEGzuFuppzaX0zSOL0qtrCTh3
XtKq3lBTCoyfuTEbVCJtiaKGILwPBSN1wXA2KKcafrG3N9dYU6NblpD+hcdudxES
1KpiWYcguN5mBq5mB8QqgLxFGD03xCq6VRDiAlH/iksV6pBCrFwfs1/DjAMtIwI1
JSyYgXwBGsjn6w7MLueYNEsbpzz2yyOr//ffbGpFqqK7J6sjlkCy92w4GAALxAnv
pxLoKH6TlSTuqfOwy9gV1x3ZU5q/4A1uk08LIQ8oUcQCNfb9oOn7KLKvvXXvTwFz
FesgwkdDQw==
=jbbp
-END PGP SIGNATURE-





[PHP-DEV] PHP 8.0.14 RC1 Ready for testing


2021-12-02

Thread
Sara Golemon

PHP 8.0.14RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pollita/

Or use the git tag: php-8.0.14RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/7e07a4a518e7714e95456823fe41e64c

8.0.14 should be expected in 2 weeks, i.e. on 16th December 2021.

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.14RC1.tar.gz
SHA256 hash:
ee1fd3fa5ba7162412da8d7cdfe6e7ea0ef582dd0a6aae5b3ca77a8d90472195
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGoVCkQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcqu4D/46QW7FYzwsezBnL1RlYLQrCGwZlb2kFxXU
/zCX3dgORjUpnwhMGdJ6nRfoaX5027Vc+Bz9PzsVhuERSoL6bRuOzPMdvNcG9hTi
3OVwaevGThN3gBM3vDIczMAThYwc8rb2bnt45BrMXvg/ttYagZcGVGhHgeY8zP6j
28lepNcF9nXrZlgZyHjUeAe3tvhyx8ZOxhVVhxfDSvMvopkphKYyDojxmtPm0qgT
Z5ZTlkV+JeqbjRq1GBsmJ3byev2Ze8ElLQfzuI6yU/kepJ0G9T/aILo9kh2vwcBf
bZr7aQhB/JXEBJJXCXjv3x9Vl9YBltC3dbqlJQ9Kbn3zTkCCzCV+Saje5c1P4uDt
9MRpv2tbK30o0+zy/q/zg8lVPgHlVYGz9qovNT10xzyVHoFnKmjhf0D1GxVbG3zl
8W9P3RG3RkbcBdhF3AOZKyUl487xbCS1wIsRjINreB6BBzEhU2kYkV/66StHWLL9
jcr3LAx5I0rnHuXkx3J1AZrcumTinnTP/STtdaKAf7hdo1q8+dRznDwirQVwnCQp
bKSr90v00bEcAfWiKHe0TwYSrCmBm6lXs31okUqGi7pn4o2DjqGgSTpIA789tB6X
KzCjSmGMhsm0hWKl4wcJ6FmRKwzWRuLUtNF98H+O9QfzSGywB4DHHCJO7cxCUzJz
2wg4DtwY/w==
=ztRf
-END PGP SIGNATURE-

php-8.0.14RC1.tar.bz2
SHA256 hash:
98ca4a47686ce3e980b2ee1107a574684924ec7934ba1f011aa4acf88d607b8c
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGoVC0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckI4D/0b7ww/jGg0JMCCMibEuODYpwvSm/HrQ2I5
hi8KhkPulOQFEj1rLm56tCT7S5pli0l449yCgGffgLcYcVWjQVUdhnJGzTcOGdcW
EtYiX4UclDUfLpZl6E66B2S9VAaA8WEdBYtFlwY9ZoQZDSjt1WvRB/aHRn737iuk
uudOwuWviTFkKOgazixP1sjq/8p/OaHDBqWkHLNUQmEptKb7UEUVum/M/38NItbt
DEIfcTaY5ABYo8Td4ymG3sQ6aBlPFW8QYykuy9T8WbbPaDZfZqTCIyzOx/x55CsL
70VMM9CCb4NiYSmeAT0q+xJME6agX1BA/YZX4EkOSZri7tpOZnBIopdF+aiYhPHJ
OpUlo7h0PlMZT+YWDOhyV5VpvyZmtijn66VjC6dBCvd7MKQs0gMGSEO5GGuJMWkH
qGOGE35ae8SzWuQLO1yGO/wq0OPXdhsjEpxzOwvr5+0pTO/1P0JccuIoA54K4zRV
uUXiBcUcAwThk9GoNVloaMSLC4l6SxtdYf+FZcfdLx+tYbOpLtNKHKZFDtvCFLfM
b3Glx+BJKWI9wB8GsB0kFPyCN0Vsof2XG9QhBIZq4wUg4B2gIBvoE7In8zc+8xNL
0qbTtzdhs2xerCMpTb17y0qhb8Ehw5vSdz2jVZIzL+omO1eeH97CFB7EQDFFnfwz
q7LcK9JTnw==
=5dzL
-END PGP SIGNATURE-

php-8.0.14RC1.tar.xz
SHA256 hash:
3514c01d5ef7453178a6a986b14c6ab5de3d2c8993dfe2fb6b9ade80e41b4a75
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGoVC0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhch5tEACRJPj4L3VeZT60L6strrKqZardTobqQsrr
De8ISbZT5s7p6FDlvSdkLn/bsFPNseh+IsUQ3jRvPcOsoNbk5b5yRLLDcwsRHC3E
z4jdWwNG8M8ldztEID9HRAk89NtUjsbCCneaGcBpSekJIfDa7v08BH9HW+RwZDjf
ERQoRMDlpJQXvObjgYaMlCcjFM1OHs3XbsnnoNoZJvGZKlS+T4IQaUdhlfVndQe6
OVzeEdaa5ArOREYGAAAyTb20OBs+bBhVenqD9ao+MeNcYJaArkvn+G+4Jq3uGWqa
6waGZtPxWEnvTboQsJUUSmDfuHxjXIqlLtg8MVvhDgC8iD6ZYzQYG2wQWORQGoxY
zHqxbLIfF9tzw+XbpZ+/c20R02mPFIsTyAXdTM2JDb8F3VWoHm8AWdMODXBBs1Jx
kZ4CUBUmAikS28t+gfRoT36xir+MdN7V3BBSgXt5NtlwGiw7F5awTvTdShzQYyws
WUEhQKasEpa75BVIMbmYpkr1LzaiUfC2ik1yUP+He89bcmR+hsUA3WVnOfpVml9o
m1eig/BfE4dj1a2EtIUGGiRK2BU564pnYR6ovquuIVaIZ8f52L96uQ1zNmMJuDAP
DAa1vJrHdUWlWo0aLxHlACT+6PitMAF1J+gsLz+CQRKuwMyOlIDSux+fE4BKZDb+
6PVf1Ma8/w==
=9Kzb
-END PGP SIGNATURE-





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


2021-12-02

Thread
Sara Golemon

On Thu, Dec 2, 2021 at 8:48 AM Craig Francis 
wrote:

> On Fri, 26 Nov 2021 at 16:47, Sara Golemon  wrote:
>
> > I'm not saying send PRs to fix them all...  Let's make PHP better,
> > together.
>
>
>
> On a similar theme, trying to avoid too much work for developers upgrading
> to later versions of PHP.
>
> Is there any value in me proposing an RFC to update *some* internal
> functions so they can accept NULL?
>
> I see developers using their framework of choice for GET/POST/COOKIE/etc
> values (where they receive NULL to represent unset values), or simply doing
> `$q = ($_GET['q'] ?? NULL)`, and other sources... where they will now get
> deprecation messages whenever they use functions like `htmlspecialchars()`,
> `trim()`, `strpos()`, `strtoupper()`, `strlen()`.
>
>
I'm not hard against this idea.  The interpretation of null in these
contexts as being equivalent to empty string isn't unreasonable.  I guess
the only objection I could have would be an academic one and I can't really
defend that.  So yeah, sure... why not?

I would say that such applications should consider unifying their own
types.  $a = $_GET['q'] ?? '';   Is there a place in the application where
empty string and null would have been distinct? i.e. Is a search for
nothing different from not searching?

-Sara





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


2021-12-01

Thread
Sara Golemon

On Tue, Nov 30, 2021 at 10:18 PM Brady Wetherington <
bwethering...@grokability.com> wrote:

> >>> …It's been merged to master, so you could stand up a build now and
> point to the many deprecation warnings you're expecting.  I'm not saying
> send PRs to fix them all, just show real impact rather than theoretical
> guessing. …
> Okay - good news/bad news/good news -
>
> Bad News: That's because later versions of Laravel dump all
> deprecation warnings straight to /dev/null by default. If you
> configure a log 'channel' for 'deprecations', *then* you get actual
> results. One page load (our dashboard page) generated 267KB of
> deprecation warnings. Clicking through most of the main pages of our
> app generated around 3.5MB of them. And these aren't full
> stack-traces, they're just messages like:
>
> "[2021-12-01 03:48:23] local.WARNING: Creation of dynamic property
> Illuminate\Database\MySqlConnection::$readWriteType is deprecated in
>
> /Users/uberbrady/Documents/grokability/snipe-it/vendor/laravel/framework/src/Illuminate/Database/Connection.php
> on line 1368"
>
> Good News: *Many many many* of those deprecation warnings were repeats
> of the same deprecated thing from the exact same place. And *very very
> few* were from the dynamic properties thing. *None* of the dynamic
> properties deprecations were from our code. Everything was from
> composer dependencies, and only a small handful - so, probably pretty
> easy to remediate when it comes to that.
>
>
Does it look like there's any sensitive information in these log entries?
You mentioned they were only in external dependencies so I'm
thinking/hoping not.  What I'm getting at is: Would you mind sharing those
raw logs somewhere. I'm sure someone will find it a fun opportunity to make
some pull requests in a variety of projects.

-Sara





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


2021-11-26

Thread
Sara Golemon

On Fri, Nov 26, 2021 at 12:16 AM Brady Wetherington via internals <
internals@lists.php.net> wrote:

> > > That's 1.5 million hours, which is 171 developer-years.
> >
> > If we're going to imagine numbers; there are 6 million PHP developers
> > in the world*. If on average they each lose just 1 hour per year by
> > making typos and accidentally creating a properties dynamically,
> > that's 6 million hours, or 684.93 years!
> >
> > So the value delivered by this change would be 4 times the cost just
> > in the first year. And then every year after that it's pure benefit.
>
>
The point of this counter-argument which may have gotten lost in the snark
is that nobody has done the legwork to know definitively what the impact of
this will be.  You're both making up numbers, and this is part of the
reason the deprecation warnings exist, so that concerned product developers
with a stake in making sure these sorts of things go smoothly have time to
test such changes out on your own codebases.  It's been merged to master,
so you could stand up a build now and point to the many deprecation
warnings you're expecting.  I'm not saying send PRs to fix them all, just
show real impact rather than theoretical guessing.  If it's as bad as you
fear, maybe we run another RFC to remove the change before it ever sees the
light of day and you become a super hero. Call you Uber Brady.  Or maybe
not a single deprecation warning shows up. Or just a couple that are easily
fixed.  Let's make PHP better, together.

-Sara





[PHP-DEV] Sponsor link on github.com/php


2021-11-22

Thread
Sara Golemon

Now that the new PHP Foundation has been announced, I've been asked if we'd
mind configuring a Sponsor button on our github.com project profile.
https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/displaying-a-sponsor-button-in-your-repository

Pro: Gives appreciative users somewhere to send their appreciation and the
project doesn't have to worry about all the tax implications.

Con: PHP has always remained unbiased regarding frameworks and libraries,
and I think the same should apply to other external organizations, like the
foundation.  There are, in fact, other foundations already in existence,
and if we send traffic to one, we should send traffic to all.

An alternative may be to link to the various foundations from php.net (and
github.com/php) with some text stating that they are all independent
organizations which contributors should assess individually.

Looking forward to thoughts,
-Sara





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


2021-11-19

Thread
Sara Golemon

On Fri, Nov 19, 2021 at 5:38 AM Rowan Tommins 
wrote:

> Perhaps there should be a section at the end of the 8.1 page saying
> something like "If you're still on PHP 7.x, upgrading gets you all this
> as well!" with the headlines from the 8.0 page, and a link through.
>
>
^^ This.  Maybe even a bread-crumb style navigation to just to "What's new
in X.Y"?  Granted, we only have 8.0 and 8.1 at this point, but it's a nice
tradition to start.

-Sara





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


2021-11-19

Thread
Sara Golemon

On Fri, Nov 19, 2021 at 2:35 AM Nikita Popov  wrote:

> On Fri, Nov 19, 2021 at 4:16 AM Sara Golemon  wrote:
>
>> In seven days, https://www.php.net/releases/8.0/en.php is going to be
>> obsolete.
>>
>> Well, that's a harsh term, but it certainly won't reflect the current
>> state
>> on the ground, and we need to decide (should have decided, weeks ago) what
>> we're going to do with it.
>>
>> There's a draft page for the 8.1 announcement here:
> https://github.com/php/web-php/pull/450
>
> So if we want to do an announcement page for 8.1, there's probably not
> that much work left in finishing that draft.
>
>
Ah, of course. Bless Roman's heart.  Yeah, we can get this polished in the
next few days and queue it up on web-php.

-Sara





[PHP-DEV] Re: PHP 8.0.13 Released


2021-11-18

Thread
Sara Golemon

On Thu, Nov 18, 2021 at 9:16 PM Sara Golemon  wrote:

> The PHP development team announces the immediate availability of PHP
> 8.0.13. This is a security release fixing CVE-2021-21706.
>
>
Whoops. Apologies for the copypasta error. That CVE number is a typo and
should read CVE- 2021-21707 for https://bugs.php.net/79971

-Sara





[PHP-DEV] PHP 8.0.13 Released


2021-11-18

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.13. This is a security release fixing CVE-2021-21706.

For source downloads of PHP 8.0.13 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/3964ae5f68cc06798bc99497821540ef

php-8.0.13.tar.gz
SHA256 hash:
b4c2d27c954e1b0d84fd4bfef4d252e154ba479e7db11abd89358f2164ee7cc8
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpQQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctBQD/9n90Vm3RE5i4rii12y+CUw76X+80ep8ASp
xd/eHDn5heNj2redkfYy0yK5ZxR96ZG7b9Seb/LTXfiwstJS2UffSq4Rv1HUJtqZ
eoQkrHS3Bmg6fRKpY6CLj0iRoJxWwson68uj9Son0GY0uk0rDMn/J7+y8kv862wj
QcZj4lyhPmyIu1Egk8lPTnUxdbvPqC8MZjQ7XfreoTVwM7zIfzTbByqjVgH41bIw
HndFz7Hu7fU/W0azQMQZW0uZUrqlnaWkUbb4AzywebBYexuJI4O3RuUcUyQ5g37p
nX77g6smOb9W0Uh5DhLHDLZxF7wDNinc97QxgKuL1GZSBNuVMYAYKEMy9FERjHXG
DkOlpyr+w3gYg1Z6k+NL1GIHMi/JWnOvj8N5Co5G3ZEqJd3yRBulJHBxx2sAD2Bt
EYu9uglrvXUrUqCwvqJRt91YOFs7kZy1t8ZRD2sG3IAMNEQeh12Ak5NWMLK6+HFV
w/mqQDnYcZNC/qLIAIqRODt3Zb6darwfug7cQUtZfw38B4kkfUVbhUvE7iTfJgXw
vOHZHlvfvun9ugN0Fv+6EfST5ga6ol+eIgakMXUdGuLqnVrkHxJODdRXewRAGrpm
NAcgFUy2LdNK2k/3oUE9uekwEoqFhNljWAGU02PFAazJBOk8c+HUjSZLEp73Zq/i
qMqQf7gJCw==
=ZAr9
-END PGP SIGNATURE-

php-8.0.13.tar.bz2
SHA256 hash:
c2419d7ba4395f44747043f4e6f5b47fa08125705fb9f88377e453068a815836
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhclrNEADAYooqUPVyJuYWBaD6g42h9LofrsObLybv
/afntIKYo1ogG7i6NHpCXKwNK/yW5CC010MVzQsVSbjmrwRXtNjqtSD344bSHhrs
ImAHfUWMVQkn/nWkdLc2MdEbxO7IohdoAQ9jfQSgZp4X8NLZTrA+ayDLc/nYZpSe
TWswS05ucubMneFkFAs/uqotvH/5W8W2jY/NVmigeD1qAikjaJaNjk45TxYvykI2
9EkplRQrguAxBlJXvzPbeeajV55f7p+0OwlXI4TI4YYpctLWff0xfsIhrnt/h6Px
a7J7alPYIHTQxot80jXsXheJvIp1BiI0J2Es2Nv+gl0gsWw78sZ887kC9X3A2uit
TOVisilJ7hSCqCH3oaAvxVjK272c04EC0Cm826IyWGidHtcVbB9+Cf89mnrP/d4K
cdg6EDwk7QJLl0nfVLyJahWUZ5Roe1PjJOwbxS/ss02iy3jLVZE6ZMTQN1TVEawC
GtlrTdieqnoLYpjq91NY17u/HKgXXOynukbu+kCSaS9v6fezermZHqkZp+YK8xrs
kKYbnxWsB0HKxXcyP4/Vglw13KiuyRT/WzSF+6VLTomrXdax3Ty82aZAbAyGtf0H
7zjgksVbalqafRv+UGsoRfXdGgqMG3HQaFLJLm9crQ8UC+I/Sx1yBro8hM48ccOR
vXbpF5ReTw==
=dyYt
-END PGP SIGNATURE-

php-8.0.13.tar.xz
SHA256 hash:
cd976805ec2e9198417651027dfe16854ba2c2c388151ab9d4d268513d52ed52
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmGUGpcQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcuMrD/9c6os7ZNv/cS5I3arv5jvMvogp+ROkHNcd
NPB+JOjIDVOReKEWYImwhJv2/tD7VdItJTA7drHK8n419nGq0qywyyQuu6aRgUTF
d2hE4+49fnQjcwZ+Bz/tM2maJ5jy0yZN6lkdBkO8lOXUAEqwPvdaZUl3mjrgPI5k
MYXidRBvNcioNqHOVkYZ9wzsuGiN81TBU/MreEPBMcaht5agautVw9XMnqJ13pZB
jnJxCgWUggvpu8KPKNCtTWOVlegkUqi13+GO6J9U2fEYb7be8edMXlTaJWXZkd9H
VlKlN+/4eXvcRQxzhmxilDpZfYhvmivj/34r3Ox1JYBHS59VCFztMLl4+7cl7D/y
z/L7U6xHlxW0O2xa6XM1SSUxxIRw8De+2FkFuWCWAkMxJefBqy+fb9jSGqB/gxys
T2vQdMvswMp0LPmhYjwOyvNXc3TCvPIRxyvdtRqMaAe3IUqkA+B81QTB2kzNPJz3
8L5t5FR5fLFuIgUGkdE7odStCakriJjsyNRAuSTzJ/X4UzMmUI7cMWpPuJ2PKzBl
ecK6DB9wBGNQfm4mvlS1vtov4XDGPRmZNx+hnad8seJpGLQ/7kAwbw9XMcvPcOkU
QfI8IZbSSF7et2Dwup8YrWRG8RrJY5MI4I5xGKYQD/WoygS9yLLrqy+kapo0ajYy
0bqxeMLb9g==
=+AGI
-END PGP SIGNATURE-





[PHP-DEV] PHP 8 Release Announcement Page


2021-11-18

Thread
Sara Golemon

In seven days, https://www.php.net/releases/8.0/en.php is going to be
obsolete.

Well, that's a harsh term, but it certainly won't reflect the current state
on the ground, and we need to decide (should have decided, weeks ago) what
we're going to do with it.

1/ Make a new announcement page for 8.1 ? Effort: High, Impact: Awesome
2/ Update the 8.0 page? Effort: Moderate, Impact: Still relatively awesome
3/ Remove the link from the banner (but still keep the page for archival
purposes). Effort: Low, Impact: Shrugs all around
4/ Remove the link AND the page. Effort: Low, Impact: But... why?

Personally, I've not got the cycles for 1 or 2, so I vote 3.  Anyone care
to do more?  Bear in mind translations will be wanted.  If nobody steps up,
then I'll plan on implementing #3 next Wednesday.

-Sara





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


2021-11-16

Thread
Sara Golemon

On Tue, Nov 16, 2021 at 5:55 PM Larry Garfield 
wrote:

> 1. If we adopt the RFC right now as-is, the market has ~12 months to add
> the attribute.  If we instead have a default-true flag that changes to
> default false in the future, it means at minimum 24 months in which to add
> the attribute to opt-in to dynamic properties.
>
>
Okay sure, but that's an argument about lead time, not about
implementation.  If we agree on targeting 9.0 for this becoming an error
(and I think we do), then the argument that's left is whether users get
notified as early as 8.2, or if they only get notified as of 8.3.
Personally, I want to give users MORE lead time, but having the deprecation
warnings come up sooner, rather than later.  Assuming 9.0 comes out in late
2025 (guesstimate based on the cadence of 7.x), then including the
deprecation with 8.2 (released in late 2022) will give users three years to
attach an attribute where needed.  If we delay the deprecation notice until
8.3 (released in late 2023), then they only have two years.

I know this is the opposite end of lead time than you're talking about (you
want max lead time before a deprecation notice even shows up), and here's
why you're wrong:  Most users don't pay attention to internals.  That extra
year you give them until notices show up will be wasted in ignorance as
they don't know they have any work to do at all.  All you will have done is
robbed them of a year to implement the escape hatch (though let's be
honest, they don't even need ONE year to do it).  The only developers
paying attention to internals@ traffic are the ones who have literally
already added this attribute to their code bases in anticipation of this
change.


> 2. The RFC as-is has no way for developers to opt-in to actively rejecting
> dynamic properties.  They'll get a deprecation, but... we're shouting from
> the rooftops that deprecations shouldn't be a big red warning, so if you
> want a big red warning you can't get that until PHP 9.  With the flag
> attribute, developers could opt into "please slap me across the face if I
> use dynamic properties by accident" in ~12 months when 8.2 ships, rather
> than waiting 36-48 months until the likely PHP 9 release.
>
>
Your premise is that, since deprecation warnings will be ignored, we should
increase the verbosity level of the warning, but only for people who
clearly know that a problem exists and can opt in to it?  I'm sorry, but I
don't track the logic of that.

-Sara





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


2021-11-16

Thread
Sara Golemon

Serious questions for all the folks worried that this is some kind of death
nail for PHP.

1. Do you have code you're responsible for which uses dynamic properties so
broadly that adding this attribute is a burden?
2. Do you know of real code in widespread use which uses dynamic properties
so broadly that adding this attribute is a burden?

All I see being bandied about are hypotheticals.  So here's my answers: In
my entire career (which granted, is only about half actually written IN
php) I can point to exactly one class* which makes use of dynamic props and
it would take me a hot minute to add the attribute and commit it to the
repo (note: This code base is running on 5.x, so it doesn't need it, but it
can handle the attribute all the same).  I don't consider that hot minute
to be problematic.

For those wondering what's the point: Making the engine better is the
point.  We won't see the payoff in 8.2, or even 9.0, but by 10.0 we should
be able to be in a better place and have a better engine out of it.

-Sara

* Not counting uses of stdClass which is going to implicitly have this
attribute.





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


2021-11-16

Thread
Sara Golemon

On Mon, Nov 15, 2021 at 11:21 AM Larry Garfield 
wrote:

> A possible idea to help make this transition (which I do support) more
> gradual:
>
> Instead of an "allow" attribute, introduce a boolean flag attribute.
>
> #[DynamicProperties(true)]
> class Beep {}
>
> The attribute marks whether dynamic properties are enabled or disabled via
> boolean.  If disabled, then they're an error if used.
>
> 8.2: Introduce the attribute, with a default of TRUE.  Exactly zero code
> breaks, but people can start adding the attribute now.  That means people
> who want to lock-out dynamic properties can do so starting now, and those
> cases that do need them (or can't easily get away from them) can be flagged
> far in advance.
> 8.something: Change the default to FALSE.  Using dynamic properties when
> false throws a deprecation, not an error.  People have had some number of
> years to add the attribute either direction if desired.
>

This is exactly what Nikita is proposing, except that instead of the
attribute being introduced in PHP 8.2, he's proposing to introduce it
EARLIER.  Roughly PHP 2 sort of timeframe.

This is because attributes are forward compatible by design and developers
can already start adding #[AllowDynamicProperties] to their code NOW.  Even
their code that was written to run cleanly on PHP 5.6 because users are
terrible at upgrading their servers despite a 2x performance increase.


The point is, we don't need 8.2 to be a soft-launch before deprecation
because precisely nobody is prevented from adding this attribute
preemptively.

-Sara





Re: [PHP-DEV] [RFC] Migrating to GitHub issues


2021-11-03

Thread
Sara Golemon

On Tue, Nov 2, 2021 at 9:19 AM Nikita Popov  wrote:

> The migration from bugs.php.net to GitHub issues has already been
> discussed
> in https://externals.io/message/114300 and has already happened for
> documentation issues.
>
> I'd like to formally propose to use GitHub for PHP implementation issues as
> well: https://wiki.php.net/rfc/github_issues
>
>
IMO the more custom infra we get rid of the better.   I'll volunteer to
update the news2html script we use for creating Changelog files.

-Sara





Re: [PHP-DEV] Proposal: Shorthand initialization and destructuring of associative arrays


2021-10-04

Thread
Sara Golemon

On Mon, Oct 4, 2021 at 2:15 PM Konrad Baumgart  wrote:

> > I have spare time this October, so I would happily get into php
> interpreter by developing this.
> Unfortunately my plans to have spare time FAILED and I'm not able to
> contribute in the near future.
>
>
I'm procrastinating writing slides for Longhorn, so here's a quick and
dirty implementation to work with:
https://github.com/sgolemon/php-src/commit/4156d9d989314b2d60d1031ab9e02faaefa248f9

Not actually sure it's got value, but you shouldn't be held back from
proposing it by a lack of implementation.

-Sara





Re: [PHP-DEV] Allowing `(object)['key' => 'value']` in initializers?


2021-09-27

Thread
Sara Golemon

On Sat, Sep 25, 2021 at 10:45 AM tyson andre 
wrote:

> In PHP 8.1, it is possible to allow constructing any class name in an
> initializer, after the approval of
> https://wiki.php.net/rfc/new_in_initializers
>
> ```
> php > static $x1 = new ArrayObject(['key' => 'value']);
> php > static $x2 = new stdClass();
> php > static $x3 = (object)['key' => 'value'];
>
> Fatal error: Constant expression contains invalid operations in php shell
> code on line 1
> ```
>
> What are your thoughts on allowing the `(object)` cast in initializer
> types where `new` was already allowed, but only when followed by an array
> literal node.
>
>
I think for consistency's sake, we'd want to provide a base constructor to
stdClass to take an associative array that maps into dynamic properties,
e.g.

class stdClass {
  public function __construct(array $props) {
foreach ($prop as $name => $val) {
  $this->$name = $val;
}
  }
}

Then you could:
php>  static $x3 = new stdClass(['key' => 'value']);

This avoids special-casing object cases in the engine while making it clear
that a stdClass is what you wind up with, and honestly I think it'd be a
useful pattern to use when initializing stdClass with defaults elsewhere.

As to whether or not we SHOULD: While using declared props is preferred in
the vast majority of cases, both for performance and for readability, there
are legitimate cases where a short lived container wants the flexibility
and convenience of an untyped, dynamic structure like an associative array
with the visually clean aesthetic of object access.  stdClass does that,
and even if deprecation of dynamic properties passes it will continue to do
that.  I started this paragraph ambivalent about the feature, but I think I
convinced myself around to a +1, though in the constructor form, not the
cast form.

-Sara





[PHP-DEV] PHP 8.0.11 Released


2021-09-23

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.11. This is a security release fixing CVE-2021-21706.

For source downloads of PHP 8.0.11 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/65bc563ad57d16069eaa7ab76b8f3046

php-8.0.11.tar.gz
SHA256 hash:
c6a461f57b4bcb46cd4dec443253b1e2e8e981466f1280093322b7864afe8be7
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEfsQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcjAND/4jpUJn5UbASCnzHlR/VUVVwt0Jg07Y5ZeM
Xt2xvxA5gFankCUa0RYJlmzd1OmNSLlOfVWTwDBvURCwjjHa9asuc3kxSAeXNeGC
7bBdygIDf57rJyN8bcNXSAK/Ld7UqXdF2MqlgbpTfNH76XtBqqN4WQwVdxGXDEq4
yhv7DcPG8d6CXF8byAs2GWP0whrGBiZQjH9Xbxn4AuWLEducivuffVr7PFtn8YVS
MXxrko84MlWn9eYo1b3L42eWuu3HRiay9BfRKgO41CQJdPxoFHrwo7IS8ePuFbGK
xV7+lSa5sCXU0Fy08vY0F/REc+ISP3Zf3kbcWNQttMsgbrT2PBHDzMXhQCGRj0tg
YA2CoX3nrcrnLxV8ELGavv3Oh3YTiBUmkfCfJCme/GojpVmANQO0qd7TOcHjXBJe
Ntp+qE6NYA8IphvRDJHLPlccFKSU6yThen1jwVHA3RZ6baWBSgVXoXssDE7Q5kt/
bjMPn5opoOZw2gYsylAp6BGpMAxsItEPRoP/UcZ1pT6IcCc3HXSmuRVlSjPqzPLH
2lHQFu0PVH3u29zngoYX8SNY4mWMZRPAyS+wkMTButMhaUSm3rFCZnZ9MFMzjRB+
zHrlYLnyZzdlj5etypv1PCcdIMMkeeM8akg+fzLQVnH+GJQITij2+WksZvizK/Hl
bmFXTRx8hQ==
=ZVf0
-END PGP SIGNATURE-

php-8.0.11.tar.bz2
SHA256 hash:
70ed874285e4010c1e2e8937bfb56b13b9ed1b3789dcaf274b793b00c1f4403a
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEf4QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhctXAD/9HFrnYdkUBYo2vD/EjpMzsN+9gPRGMb5YT
e8GOoh6MhVAT9kSS5EdNRfQeaPnL+do2nSlZKKwxEU/VS88YJPa9eD/w9ceuLVs5
ev4fCN5TcYMJoMLBUQKJvYcOWCyJXHB6lKOo7zPnOukdtpSyNMj0EhyZY0UwlSIO
wydbXYmKtcxcHZvNh2V6HWZecUeEMu5cFRFzr96G5d8POo0LpW4YOOp88acd7aTN
qXkRF2BTQha5Jnl6COBDnk4YFbMevsnOAS395CUTxEe6yjODha0kgNHXzqoaPX13
qmILPxX56Aq3II+Gmg5TOwsskz4DZkgd/U+g967LjyqHlNMBVtKLUo5dp98hY+6y
t7g2WA8kPr3I0FJ/zIvwq8Zs+NoZUUs56iJoP0ERuTE6M/92hbyY/dT2QlT8v5z7
m9fISPYm2D7qENdP5xVaVBJjFLiIDhWaWW2doEMyzwYkq/kgX2Ni61eTP9f55iRR
DDtacdLvuE35LFdTSQ1N8TQgf8e3Q1SANe+nDnhOGkZoR/qW4oyMR30PWNvcJtFF
1RgMoWb/PwrQvQXoOVz6ofjkf+7LfMN1CMP8xIjPJ+cFOh8fr+1KHLzl3mLqkWy8
vKfVXhNVFn6sZz4C8xwVp6m3iGHa25Dm/jOLcjNBj781AFQrHT7AdNxdRJaoUEVd
2HppVL5QCA==
=Ik7I
-END PGP SIGNATURE-

php-8.0.11.tar.xz
SHA256 hash:
e3e5f764ae57b31eb65244a45512f0b22d7bef05f2052b23989c053901552e16
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmFKEf8QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcnqsD/4wSJ/Td0grw9x94Q+rwceRyeo49H/l1t/f
UYt+a6F+EvM/ZxNKGe8gGBsDW4C2J0zBA53GLKNMG/m6tMhBQF3qY4aRJrx/lS6a
VT2SOpfPTiezG31FIkZsx1i4ISLdRpHJfAGKgHWtDlb6m6CJQSGLaIShYwjWVZ2W
M3Bg5ijjGqVIPYUd5LzJX2tqtq48HA8PiAbFMb1OPcwu/1L8rssHklgBcBn2+bc+
ecYt3nhqQyboCfuUuwTofiM7z8tLp8RipMmw2o/oDPVgenYGiQGrcNKOLkxqvblz
pNAv30EhmHqmncoGivoW9qmBSlef6Jafzvy1U4Nmnwc/1r25D47PwNw9S8DTlDjX
nYLAIudAK17fo+fnhBB0S5E7qj7mBfslKDOKACDaGUF0Ynufuy61YC/wbfKphriw
hMq2XqfYRSUvHYoN/upJr4cB4xPzj71odshAgOdSJdT6uTbtIM+MnF1JxeE2Dzz9
RCUB8jhNBBukR0L3sO1Rq5HBMEQgQntZC7KW7CRjW3lwQGuKCPzlxCzvZlinie9Q
LOEJWnyfq+XerAXjdgBmH133nWyLsRQbGQx9szWTctu59YBHQUEwRw9mIcVtjv4Q
cXmMitzvFH+Gsr/mxfQ2nn5qXmd1YQWJZFvfoNUWrYEhknZH80iq4LoOiMpKwsNd
IEVfwu7kTQ==
=DMzd
-END PGP SIGNATURE-





Re: [PHP-DEV] run-tests SKIPIF caching can be problematic for third-party extensions


2021-09-15

Thread
Sara Golemon

On Wed, Sep 15, 2021 at 12:22 PM Jeremy Mikola  wrote:

> I just discovered that run-tests.php was changed to cache SKIPIF evaluation
> since 8.1.0beta3[1]. I believe ext-mongodb ran into the same issue as
> mysqli[2], as we use SKIPIF to check that database contents are clean going
> into a test. The present solution in core is to check SKIPIF output for
> "nocache" [3,4] and allow individual tests to opt out of caching; however,
> I'm worried that won't be portable for third-party extensions, where we
> test with run-tests.php for each version of PHP that we support.
>
>
If the phpt file outputs "skip nocache" then that will skip without caching
on all versions, won't it?  In 8.1 because it has the explicit 'nocache'
provided, and in older versions because they don't cache anyway.

Am I missing something?

-Sara





[PHP-DEV] PHP 8.0.11RC1 Available for testing


2021-09-09

Thread
Sara Golemon

PHP 8.0.11RC1 has just been released and can be downloaded from:

https://downloads.php.net/~pollita/

Or use the git tag: php-8.0.11RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/2fa8a0f29d635c3da844fbdaf0bc6609

8.0.11 should be expected in 2 weeks, i.e. on September 23rd 2021.

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.11RC1.tar.gz
SHA256 hash:
17c70798f2cd7f99824df62a75aa89476916f88a01c791c32a8baefb4af2dbc4
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmE3gQMQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvCqD/9KB1vydZwgNA1iNwwmcwVlCx+LV26kfw0+
kZOs8q+nrnquINkT/+bFFBWFLBGUfxHUFrfVrEpTtoiAupEWt8/QKDIiEnmr1+Pz
oJL7Tjne2/uAl/lcgVhM15PLMiz4rCYXFoFYaKRJEM5Aczw7xs7qhTKrLKPjWQgu
Jfj9W2bjLCGXLoFyHth9MF8dLPjpdX+2RKsuvCjdqZPAAw0TQM0uheM2ysi1rXUk
lJN7PSl08B/nKfSILxNu+++/dvjr+Km6Cdrlr4GAOyzpO4O9EOXQ1nmHz9UZyTHv
fAB91f/SrdW6eQxGQOvTaQLHkQcPb2cm6+6XPOnpmn7fQNemr0MBdHuLdPsbtn8L
5tFtLxYQ6A6EBlW58XOYiYU52bS2INYvE8D8pYMl6N/Dn2+JbKYS1ZcMtEY/sYE0
3IytpCKGPUXAmzM3XPlnwuSLtRbTlmwim5uUh7ftAbjKG8tkouir3tRRmM2z4rGH
+NvyQaaejq66/ecukqPfFY9e1d6ZbwgvQrSYkh0ITZYQCq8iaX1Mqnvlpe54nFLU
Vc/l6GLlaAMbBqBLrh9+rfOamgGDbaOZ9/21aT2vqY7dCLCB/7+D13uIfqoN6rSd
RWetRQynP++Cfk8wJtTm0PvwajhBNuqWghQsX/csJ73bleDo1qSuv1Mum7smXEKt
tSyE7qJqCg==
=bhyV
-END PGP SIGNATURE-

php-8.0.11RC1.tar.bz2
SHA256 hash:
98fa0e7f57e40926b81c2285ba7a5805defb8cd79814afda7fdbceedd26064de
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmE3gQgQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcj/0EACfB1GpnWB80s5uOq6qGrsjhybzmOpr56+w
qX2lqIXcMNEF/Nkw7IxAUeC/FTa48kafYoEgT9aKwqJrPAdZ+R4tOADMO5V5TJUf
NEEaRFweDzkwBlRIJhij4cGzOM0sSL+p4myxbtvCedR5+SZarPQgm5vg3axk1OuX
oi+y5eggGdBJQbMrsCoPvoRWT2k4fhGo79EfKkLQBSU0d7kZn7ZKgF4VILWLBexv
A+RE4R1DMJODa7ijtthxMWKnwubg7QxjX54DCgpqltLpL8AZSrhsZsVFeoGPgsHd
ZXzwH/KI8hyScWhmcoUJpw8jHtq3pjc62zgi92oLPjn+JINbyeLLpnAQqKoi0u03
p2mqkG8C4g8g2ciGOSZtijlSCAODOCwxjBRJov1gcpFTSZicUcvNZoFnCSVPZ4km
J4SWVOCaRJbE7jbGGGcPWOVjiyPPLa6H8jUfjiIzrhsnp6z+8kx5dh8DSwC0cKSy
pkix1g6cgu/k4zTcbD5vH0f4kkBb5lDPcIy+0XcOV2+8kBquC1xTjBPx5DdJ5ktM
DMdFJcEHy2BW2Xy6t0r/yqYf63UEbEu0+jjFkRRkqb80dbtiXVz3yOZgXcHCdPfo
iLzD7fkJVAJWmdPsw6uLsvNR0YoVtfdnsLrMUEecwCoiT6aG9FPvzaAg+nPXgwxG
XhfxZ+J32Q==
=H+sW
-END PGP SIGNATURE-

php-8.0.11RC1.tar.xz
SHA256 hash:
d8f19c350ff7abf7282a33aff5fcf218ee24e72b1c860e1ec083c4f3533bb665
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmE3gQgQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckrYEADifGd6jeXFXPnRdZc+WNkI66ESk1WETS4r
j1dAe2n2rQr61jt9c8DtFWEscCv5apSxYBXG6g9b9b2aFY9pmGtSmIKJQksb/jzn
csj8zyy8TjfVyZAUHdKELeoDj9UfIA8NznRRFjd5opzGF3c1qCrnYXSEXPK/jFxc
2+1VKukyjyRdNW/zR91nHKuBxoOeE35hCpBOagpZsPIYBl5KayZDTLxJfDNSG64x
n5xAiECc5CWfdeJoaCCtRXUbUK9VYl/omD8cLkCPeybwzJTwaUgmS2xJz+xHw8rN
+BUOqE2W2ACkk9TB4AwM1ezNNh3JG2LFjasnEntIa315Tc2/zbyQ+2lfxUQNdFBB
u9MCN+1I5wx8R+tmGG2NADcX7MAZZAs1xcFMDlp+pM8nThgoph7gmlKz3oiqURND
MaomlSDPanCWftO4sMKuWsn5j3Z3NtDW8Y/7xJ/3gk04OqRUN+HlF6h9cjBm3wgJ
i6Hp2e0CvN+XLadKbtvTptLd55oB5gLPegf9QJ6fDdItWRAKguSAAmKhJypJW6Dz
CZfmnGNIMQFy8139FKE0WDCzsDFO2MH4fR01s7qIRKQZE/bF9q8Y8jjZ60TEMQIF
gfwuUgYNthaHnqXWBHjnTvpjFNZbW27+IvapPeddN3lBX2ZMLviZSAcaJ520rhIP
odt6YbQyIQ==
=sAMv
-END PGP SIGNATURE-





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


2021-08-26

Thread
Sara Golemon

On Thu, Aug 26, 2021 at 3:34 AM Nikita Popov  wrote:
>
> The crux of the issue is what our end goal is:
>
> 1. Require users to explicitly annotate classes that use dynamic
properties,
> but otherwise keep dynamic properties as a fully supported part of the
core language.
>
That's how I initially read your RFC, what I'm hearing here is that your
quite explicit goal is:

> 2. Remove support for dynamic properties entirely. The core language only
has
> declared properties and __get/__set, and nothing else. stdClass is just a
very
> efficient implementation of __get/__set.
>
If that's your position, then the `extends stdClass` approach makes sense,
because the dynamic properties HashTable can live in the object's extra
data offset block and the get_prop/set_prop implementations in stdClass'
handlers are the *only* things which know about dynamic properties.  That
represents a significant advantage to the engine for the "happy path" of
declared properties only.  Every (non-dynamic) object is a word (8 bytes)
leaner, and the branch points for dynamic property access are limited to
the only place they can be used, and where the typical result is positive.

Starting from that argument, your RFC begins to look more compelling.  I
was definitely not starting there on an initial read.

I do still have reservations about enforcing stdClass as a root for any
class which wants to use dynamic properties.  It's messy, but... to
paraphrase what you said about going with an attribute approach... yeah,
someone could make every current root class in their application explicitly
inherit from stdClass without any ill effects in PHP < 8.2, with only the
exception of external libraries being a problem.

So that's the spectrum:
- Opt-in to strict behavior: No BC impact, least benefit to the ecosystem
or the engine
- Attribute/Interface opt-out (goal#1): Moderate BC impact, ecosystem
benefits well, engine benefits a little, but not much.
- Extend stdClass opt-out (goal#2): Highest BC impact, ecosystem and engine
benefit most.

Goal#2 is bold.  Possibly not-too-bold, but it's not clear to me where
dynamic props are being used today and how many of those places can't "just
extend stdClass" for one reason or another.

Goal#1 might be a stepping stone along the way to Goal#2, as it will give
us something clear to scan for across major frameworks at the very least,
but that is going to push us from removal in 9.0 all the way out to removal
in 10.0.  If you're keeping track, that's gonna be circa 2030 give or take
a year or two.  That might be dangling the carrot out a little too far...

The purist in me wants to be bold.  It also wants some hard data on
existing usages.  A simple grep isn't going to cut it this time.  We're
going to need to run some static analyzers on some frameworks and
libraries.  Who's got it in them to do the research?

-Sara





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


2021-08-25

Thread
Sara Golemon

On Wed, Aug 25, 2021 at 5:03 AM Nikita Popov  wrote:
> I'd like to propose the deprecation of "dynamic properties", that is
> properties that have not been declared in the class (stdClass and
> __get/__set excluded, of course):
>
> https://wiki.php.net/rfc/deprecate_dynamic_properties
>

> This RFC offers `extends stdClass` as a way to opt-in to the use of
dynamic properties.
>
This makes the assumption that existing uses of dynamic properties are all
root classes. I don't think that assumption can be made.

> Some people have suggested that we could use a magic marker
> interface (implements SupportsDynamicProperties),
> an attribute (#[SupportsDynamicProperties])
> or a trait (use DynamicProperties;) instead.
>
My gut-check says an Attribute works well enough.  This will unlock the
class (disable deprecation warning) in 8.2+ and be ignored in earlier
releases (8.0 and 8.1 would need an auto-loaded polyfill userspace
attribute obviously, but that's a tractable problem).

#[SupportsDynamicProperties]
class Foo { ... }

> The Locked classes RFC took an alternative approach to this problem space:
> Rather than deprecating/removing dynamic properties and providing an
opt-in
> for specific classes, it instead allowed marking specific classes as
locked in
> order to forbid creation of dynamic properties on them.
>
> I don't believe that this is the right strategy, because in contemporary
code,
> classes being “locked” is the default state, while classes that require
dynamic
> properties are a rare exception. Additionally, this requires that class
owners
> (which may be 3rd party packages) consistently add the “locked” keyword
> to be effective.
>
I struggle here, because the opt-in approach is the most BC, but I actually
think you're right.  I think[citation needed] that dynamic props are
probably rare enough that as long as the escape hatch is clear, we can be a
little more bold about nudging the ecosystem forward.  I will counter
however, that the same issue with 3rd party libraries applies to opt-out as
opt-in.  A third party library that's undermaintained (and uses dynamic
props) won't be able to be used out of the box once we apply this.  I don't
think that's enough to scare us off, it just means that the opt-in side of
that argument cancels out.

-Sara





Re: [PHP-DEV] Guidelines for RFC post feature-freeze


2021-08-24

Thread
Sara Golemon

On Mon, Aug 23, 2021 at 5:57 PM Tobias Nyholm 
wrote:

>
> Situations like this often requires a judgement call rather than something
> that could be defined as a policy.
> I suggest the release managers always should be in agreement before a RFC
> is created during a “feature freeze”. If the release managers agree that a
> change can be added, then the discussion and the vote should not consider
> “if it is too late” or “this is rushed”. I think we can trust the release
> managers to make the correct desiccation without an extra policy.
>
>
Agreed, and I would say that we DO have a policy.  The policy is that the
RMs make a judgement call in the moment.  I still think the attributes
syntax was appropriate to make an exception for (given it was a new feature
and this would be our last chance to refine the syntax), as was the
nullable intersections case (the additional change to the engine was
trivial, while providing notable benefit).  So I would say we don't need a
strong policy saying "exceptions in these cases only".

However, I'm all for some definitions of best practices and considerations
to take into account to make the decision making process more predictable
and less arbitrary.

TL;DR - This RFC sounds like a great idea, assuming appropriately scoped.

-Sara





Re: [PHP-DEV] Shut down gcov.php.net


2021-08-04

Thread
Sara Golemon

On Wed, Aug 4, 2021 at 7:43 AM Nikita Popov  wrote:

> On Wed, Aug 4, 2021 at 2:25 PM Christoph M. Becker 
> wrote:
>
> > I suggest to shut down  altogether.  It is barely
> > maintained for quite a while: PHP 7.4 builds are failing, and there are
> > no PHP 8.0 builds at all.  We already run a coverage job on Azure[1], so
> > there is no *need* for this site anymore, and we can't spent our time on
> > more useful things.
> >
>
> +1 to shutting down this server. Coverage is now on azure and also
> published to https://app.codecov.io/gh/php/php-src/, and valgrind has been
> replaced by asan jobs. Newer PHP versions don't work on gcov because the OS
> is too old.
>
>
+1; I've just checked my calendar and it's not 1999 anymore.  Put 'er out
to pasture next to git.php.net

-Sara





Re: [PHP-DEV] [RFC] Under Discussion: Default User-Agent for cURL


2021-08-03

Thread
Sara Golemon

On Tue, Aug 3, 2021 at 4:45 AM Hans Henrik Bergan 
wrote:

> fwiw i think no self-respecting codebase is depending on an ini-setting
> being correct for the ua in cases where the ua is actually important, so
> the breakage should be minimal.
>
>
In my mind, this is either an argument in favor of either NOT adding a new
INI setting (rather applying the existing user_agent setting to curl), or
doing nothing at all.  Code using curl already knows how to call the
precisely ONE line required to set a user agent, or more likely uses a
wrapper which simplifies cURL's archaic interface, in which case it's that
proxy which should be setting any default UA, not PHP.

And on the subject of PHP_INI_ALL/PERDIR/SYSTEM.  The answer is ALL.
PERDIR and SYSTEM exist either for technical limits (something gets
allocated and has to live across requests), or security limiters.  The
former certainly doesn't apply, and the latter wouldn't achieve anything
since the UA can always be set explicitly on any curl handle.   PHP_INI_ALL
is the only setting which makes sense if we add an additional configuration
(which I don't think we should).

-Sara





Re: [PHP-DEV] [RFC] Nullable intersection types


2021-07-26

Thread
Sara Golemon

On Fri, Jul 23, 2021 at 4:58 AM Nicolas Grekas 
wrote:

> https://wiki.php.net/rfc/nullable_intersection_types
>
>
I've commented on the PR and in R11 a bit already, but I'd like to state my
position here for the record.  I do see the value in having nullability,
but I can't disagree enough with the `?X` syntax no matter how
technically right the argument about operator precedence is.  Even ignoring
that literally nobody carries around a complete operator precedence table
in their head, we simply can't predict how making this decision now will
impact future plans for combined intersection/union types.  The same
argument honestly goes for every other syntax proposed, including
`(X)|null` which is also prone to making things worse.

Nullable intersection types *IS* an implementation of combined
intersection/union types, even if a narrow one. Those have not been planned
out or approved, and they're too broad to sneak in post feature freeze.
Period. Let's take the coming months to flesh out the edge cases on
combined types.  Let's maybe even look into type aliasing, which may have
the side effect of making combined types more readable (or maybe less, who
knows!).

Most importantly, let's accept the fact that PHP's release cycle is only 12
months and we had pandemics that lasted longer than that.  Next year is
right around the corner.

TL;DR - I've decided my vote.

-Sara





Re: [PHP-DEV] array_merge() inside looping optimization


2021-07-26

Thread
Sara Golemon

On Sun, Jul 25, 2021 at 4:35 PM David Rodrigues 
wrote:
> Anyway, I don't know if this is actually possible, or if the cost-benefit
> would be better than what there is today. But I believe it is a path to be
> thought of.
>

Sadly, no.  The function doesn't know where the variable is going to be
stored to, so it can't know if the one reference it's receiving is about to
be overwritten.  Technically, the information is in the op_array, but
exposing that to an implementation handler is... dangerous and sets a bad
precedent.

A much more direct and maintainable solution would be to introduce a new
function that intentionally modifies by reference.  This doesn't give us a
free fix for existing code, but it does provide a path for new code to be
more efficient.

So then you have to ask, should we kitchen sink something in for this?
Maybe, the perf argument is compelling.  I'd also argue that this request
reinforces calls for type methods.  $arr->push($otherArr);would be a
stronger candidate, for example.  In fact, I think the DS extension might
actually have what you're looking for already.

TL;DR - Maybe look at https://www.php.net/manual/en/ds-map.putall.php ?

-Sara





Re: [PHP-DEV] [VOTE] First-class callable syntax


2021-07-05

Thread
Sara Golemon

On Fri, Jul 2, 2021 at 5:51 AM Nikita Popov  wrote:

> As the partial function application RFC has not been accepted, I have
> opened voting on https://wiki.php.net/rfc/first_class_callable_syntax. The
> vote closes on 2021-07-16.
>
> This RFC uses a syntax that is forward-compatible with partial function
> application. Should it not be accepted, I'll explore alternative syntax
> possibilities.
>
>
Was replying to a comment on reddit which made me look closer at your
implementation. It looks like this does NOT allow for use of function-like
language constructs.
e.g.   $e = echo(...);  $p = print(...);  $r = require(...);   // etc...

1/ Is this intentional?
2/ Is this actually a good thing?

I'm actually of a mind that it's a good thing, as surprising ways to reach
eval() are foot-guns waiting to happen, but wanted to get confirmation.

-Sara





Re: [PHP-DEV] [RFC] Add parse_query_string as an alternative to parse_str


2021-06-23

Thread
Sara Golemon

On Wed, Jun 23, 2021 at 5:02 PM Kamil Tekiela  wrote:

> I would like to propose a new simple RFC that aims to add a new function
> called parse_query_string as an alternative to parse_str.
>
> https://wiki.php.net/rfc/parse_str_alternative
>
> The functionality stays the same, only the name and the way of returning
> the array changes. While it is a rather insignificant change, I believe it
> is one step closer to making PHP cleaner.
>
>
There's a potential alternative option that doesn't require adding a new,
parallel function.  We can use execute_data->return_value_used to figure
out if parse_str() was called with the result assigned to a local var.
This is overloady and probably a bad idea, but it's an option.

if (ZEND_NUM_ARGS() == 2) {
  // Put result into by-ref second arg
  // parse_str($str, $refResult);
} else if (EX(return_value_used)) {
  // Put result into return_value
  // $result = parse_str($str);
} else {
  // Put result into EG(local_symbol_table)
  // parse_str($str);
  php_error(E_DEPRECATED, ...);
}

Realistically, your approach is probably better simply because it doesn't
depend on the assignment as a side-effect, and it'll be good to have a
migration route, especially one which gives us a function with, frankly, a
much better name.

That said, and I'll sound like a broken record here, but this is another
case of being something that can be sorted in userspace trivially:

function parse_query_string(string $str): array {
  parse_str($str, $ret);
  return $ret;
}

Kinda +/- 0 on it at the moment.  I'm less hostile to it than
str_contains()/str_left()/str_right()/etc...

-Sara





Re: [PHP-DEV] Introduce str_left/right In 8.1


2021-06-23

Thread
Sara Golemon

On Wed, Jun 23, 2021 at 2:10 PM Mike Schinkel  wrote:

> I have frequently heard the justification of maintenance burden mentioned
> as an objection to adding specific features.  And in many cases, it is easy
> to see why future maintenance burden would be a concern.
>
> However, it *seems* in this case that these functions are so trivial to
> implement that once written and documented they would likely never need to
> be touched again. But as I do not yet know the internals of PHP I obviously
> do not know that to be a fact.
>
> Honest question: Would you mind explaining the type of maintenance
> required for simple functions like this?  What is likely to change in the
> future that would require maintenance?  And would you mind giving a few or
> at least one example of a trivial function that did need to be maintained
> after it was written?
>
>
Honest answer. I won't personally feel any pain from adding these
functions. No more than I felt when str_contains() was added over my
objections.  Nobody maintaining PHP will feel significant burden from
them.  They'll sit in ext/standard/string.c doing their trivial work,
opaque to the jit, and they'll get used or not.  If cluttering the kitchen
sink with one more unwashed utensil makes someone happy, then fine.  I'm
not going to vote for it though, because it belongs in composer/packagist
land, not in core.  I've listed the reasons for this in the str_contains()
threads, feel free to reference those, they're still valid and correct.

-Sara

P.S. - I don't actually think the octet versus codepoint versus grapheme
argument can be particularly persuasive given that our core string
functions aren't encoding aware in the slightest.  That ship has sailed.
It is, however, another argument for doing this in userspace where the
tradeoff is far more obvious, and dealing with alternative multibyte
engines and/or polyfills is much more facile.





Re: [PHP-DEV] Introduce str_left/right In 8.1


2021-06-23

Thread
Sara Golemon

On Wed, Jun 23, 2021 at 9:15 AM Hamza Ahmad 
wrote:

>
> Since feature freeze for 8.1 is approaching, I want to request two useful
> string functions that exist in various languages-especially those that run
> on web servers and used in databases. These are respectively `left();` and
> `right();`
>
>
Sorry, you spent several paragraphs insisting that these are
common functions, but you didn't explain what they're meant to actually do.

Using some context, I would assume you mean this:

function str_left(string $str, int $len): string {
  return substr($str, 0, $len);
}

function str_right(string $str, int $len): string {
  return substr($str, -$len);
}

If that's the case, then why?  As you can see, the existing
functionality available is trivial to write.  You don't even need to know
any particular amount of math (which I've been recently informed shouldn't
be a prerequisite to writing software -- shakes fist at clouds).

Am I misunderstanding what these proposed functions should do, or am I
underestimating the difficulty of typing a zero or negative sign on certain
keyboards?

-Sara





Re: [PHP-DEV] [RFC] is_trusted - was is_literal


2021-06-23

Thread
Sara Golemon

Resending this, because the mail daemon sent it back as spam, and we
shouldn't be running our own mail server any more than we should have been
running our own git server.
Seriously. What about this looks spammy, I ask you?

On Wed, Jun 23, 2021 at 9:36 AM Sara Golemon  wrote:

> On Mon, Jun 21, 2021 at 6:29 PM Craig Francis 
> wrote:
> > On Tue, 22 Jun 2021 at 12:18 am, Benjamin Morel <
> benjamin.mo...@gmail.com> wrote:
> > > On Tue, 22 Jun 2021 at 01:06, Derick Rethans  wrote:
> > >> On 21 June 2021 23:37:56 BST, Yasuo Ohgaki 
> wrote:
> > >> >
> > >> >The name "is_trusted" is misleading.
> > >> >Literal is nothing but literal.
> > >>
> > >> I agree with this. The name is_trusted is going to be the same naming
> > >> mistake as "safe mode" was. Developers will put their trust in it
> that it
> > >> is 100% guaranteed safe.
> > >
> > >
> > > FWIW, agreed, too. Trusted is vague and may imply some false sense of
> > > security. Literal is literally what it says on the tin.
> > >
> >
>
> Yasuo's contrived "faking it" eval example aside, I 100% agree with
> Derick, Benjamin, Levi,
>  and everyone saying that `is_trusted` is quite possibly the worst name
> that could be
> chosen for this. ((Okay, they didn't say that, but I am))
>
> Why not call it `is_safe` and really embrace the bad idea that was
> safe_mode properly.
> No. Nope. Hard no.
>
> > I can follow up properly tomorrow, but by popular request we do support
> > integers as well (could be seen as stretching the definition of
> “literal” a
> > bit).
> >
>
> Is a hard coded integer not a literal value?
> Nothing about the name 'literal' speaks to type, only to provenance.
>
> > Then someone said they wanted to check if an integer was a literal too -
> > but because of technical limitations, it now allows any integer,
> > regardless of where it came from, to be treated as a literal.
> >
>
> Oh, I missed this.  Yeah. No.
> If the provenance of an integer is unknown then it is neither literal nor
> trusted.
> It's a grenade and precisely the kind of thing that breaks any attempt at
> safety.
> Why can this not be tracked?  Is there no space in the zval to track
> IS_LITERAL
> as a flag rather than (and I'm making guesses about the current
> implementation here)
> storing it off the zend_string?  As a zval flag, it becomes theoretically
> applicable
> to any type (though for obvious reasons resources and objects have a hard
> time
> demonstrating literality).
>
> > That said, I’m really glad that the only issue we seem to have is the
> name.
> >
>
> As I've said off-list more than once, I'm not a fan of this feature in
> general as
> it provides a false sense of security, so no... the name is not the only
> issue.
> Using a loaded word like 'trusted' just makes the false-security
> implication worse.
>
> Take all that as you will because I'm probably still -1 on the feature
> overall
> regardless of the name, so my opinion on the name probably doesn't matter
> in that respect, but for me at least, it turns my probable -1 into a
> definite -1.
>
> -Sara
>





[PHP-DEV] PHP 8.0.7 Released


2021-06-03

Thread
Sara Golemon

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

For source downloads of PHP 8.0.7 please visit our downloads page:
https://www.php.net/downloads
Windows source and binaries can be found at https://windows.php.net/download
The list of changes is recorded in the ChangeLog:
https://www.php.net/ChangeLog-8.php

Many thanks to all the contributors and supporters!
Sara Golemon and Gabriel Caruso

Release Manifest here and below:
https://gist.github.com/sgolemon/88036ae8992ac0c557fa0d16d56c3887

php-8.0.7.tar.gz
SHA256 hash:
1e7462455bec8062ef3fc7c74f1f496417cb80aa374ce11edb35015de248c3c1
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmC2gaoQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcmLZD/47prEC7Gkh+FYtW5khIpsXLjPOOsZpbvp+
b9ZthxKJHGPYVFOYLDmg6u7D8IcL1oFtC1uRWez1ms18kX7BzNp/6Z0iHz454vYt
uVxWXwTPlRL1AlVgmYsXLNERj0HoPb2B7KKsXuxOf7UUyyMPALv0NKAKdJ3gQmck
sHUGUYQSrb36LajMFTSQWnAjoNuryKM+aMTI3mAF3+pLjlnaWGxzqsCvdDbjqaJy
3Lj24jjTwYpshgrYDYO0Y9Y/hyXSX29JnE9rkmkyvFWnvicuejFOY7P0rg1jeqQT
SdeL1iccqmI08jVwWs+wkjclKVYF+qusmPs7gFisUFtOtpiaPlqa4q9Llfpp8iwL
nGcsyLihieZWvk63cPtJJEfTmmG2dpy6zIcslObMUn/uxQDxruawf8m3QPjT5b4t
9RWSFGJ3kHCmH2IJTwjuT3XQS8KaR0xqngl0izbJgiHGS9BNyFwiuCfY0Gfhad/R
H5nMg9qc2zdCv2OjOrPcSzCH26pMgqkHiNjNsQQCIRzAyOfjGHEJlEr0je3bnspc
JABNwQ+2jMmUw6nzSnas48kTj/Q+Fxn4uMdv7cPv0Tdp1HAdgRmCM/VolCUtVZes
ilFJ1FtCB2jPjoD4S4XFwHK+WNYVlNqwyELMQf4OMUPGtlKblspNf+enJrfI7GYC
GkKrYpBDDw==
=rwby
-END PGP SIGNATURE-

php-8.0.7.tar.bz2
SHA256 hash:
72b2f2c96f35748b1d6e8a71af4ead439b17129aefe611eb0baf1bd313635f79
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmC2ga0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcl4KEACOFjBMaebUSViTS5l3/s6osRrTHhajCc8a
X8zmNpEGcm5xB+UBv5uJxPiVXAPiztsNTY4ZOZpBTD8j5cD2OL5jFBdJ3ULTMx15
RcZKLgnwhxycNGO7oC/NgrgTkOA6jf0lQglszDL5B0i6RgzP7Zh0UdfHNSocnMcY
IAwLv3Qi75dY0OWrKs3dVZES9Qpr/ntit1ml5iFjBs4/rc2avq9RSgiLiJJwDcKy
iIN4G1qDxc8OLY790kCwBQVsiaWNpiqRGWi5dzyVfN/POfRd8vICRw4mcYCSYCwJ
BHLb4KTM2KAJdg+T56RfPy5kEnE1UQMCU1YEJkLxgKN557oTg2VhzhJ+UaCcBlwK
ng1bj0UcVgVqg7/7jfSYs1C3EF1jfiIXzaOJfgXXCYTzw+KWZNmX6v1pLLhhw6Lu
/GXUQA2ximN3MAM4jxjpOudszDeSJpAgC2uwwHj05PEorz3QmxmJNe87LyXXBavn
n9TuG4YoN0Uybv1j2cDe17dIgGna0lotdsJVgUD6iRdNc1jtlZDpwAj/NuvqognR
RwRZFTpJTU6Easknvi1otfnCwqu0QLp1GK/jzRd/dqP9n2zeDEA3PAuscPdIDLHj
vkNKvuPXV5V6/4dV/8/1bv7Ezc9sM88kfpXE9r6SrS4BaGu31ZjNL2/2n7IREvzL
EYLuPMAIRA==
=aTpp
-END PGP SIGNATURE-

php-8.0.7.tar.xz
SHA256 hash:
d5fc2e4fc780a32404d88c360e3e0009bc725d936459668e9c2ac992f2d83654
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmC2ga0QHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcvdREACjK5r1EkvRNMo+9H5JSGaJQqVYbe9h4u0M
64StXezBchDfDCvKil7rtXtP65L5x48B8Phs1i9CX29Y+vhPo0LoiB7iLvrG0tC+
POvdJkbh5uuJyxjZEKH+G35V0HP75N6xDckL82VSXzg9eYtTbdBZXzx1WwpHWBPz
2PZBdOms0YHv2kjtLS7XZDhNDoHTOGIBQ92Lh8ruUYRue5zY9Aw9SqvLH/UjWj/V
xs2DbvoB8TbTYwoOnjqsQopm+71wf4oMD7zVdbdmk5dNGnxrISstL/yLFniJFTgv
E31q27L4LBQnMh4xP9asV92Va8c45EYtCJ44hc/AUScjZr3u1+mRFAg2uw3BqPbW
BeYBnTTtvzTAGkbyjHgcrI7oM0VOP0pNVzVLqIox/1v9Q5+KxSU4T+MgB+6lqaIi
qeI6gCcPmHLMkODbkl57S1IzRE8kwopT/ughggPwCl1iyEMIUG4QLgKThOA1Re6w
/1gwozV4g9MoVBlczll6zVkV+hAJTA+erNG8ig9yef8ZYYHxdCVmmehG673CzCZR
1S5J1ie/6Haa5pvo139AFfAmhicffUQ9DNiaDN5i4DIhTipSUnKMw2j6W9vrl7Al
gnCBV5WnJFJtL1Q+wwyQnrOLmcIaVYxQpJ1kIWkgTxyLnOk0c8OvyJY6nsG0u6CW
H3uvYSxY5Q==
=4Khh
-END PGP SIGNATURE-





Re: [PHP-DEV] Escape \0 in var_dump() output


2021-05-27

Thread
Sara Golemon

On Thu, May 27, 2021 at 9:07 AM Nikita Popov  wrote:

> Ah, I think I explained the original issue badly: The test runner output
> isn't really a problem, or at least I never perceived it to be.
>
> The problem is that if you change a test that contains a null byte
> anywhere (read: in var_dump output), then github will not show a diff for
> that file. You can see this nicely in the proposed PR itself:
> https://github.com/php/php-src/pull/7059/files Most of the updated test
> files show up as "Binary file not shown." As you can imagine, this makes
> review hard. Using the .patch file doesn't help either, because it only
> contains entries like:
>
>
AH! Yeah, I completely misunderstood the problem space.  I didn't imagine
for a second we had non-ASCII in any test because that's bad and it should
feel bad.

Okay, then I still disagree with changing var_dump()'s output, but for
different reasons.

So take Zend/tests/bug60569.phpt for example, which has this EXPECT section
(where ^@ is actually the null byte):

--EXPECT--
string(20) "Some error ^@ message"

Instead of changing how var_dump() works in order to produce different
output, I'd change the EXPECT to and EXPECTF and add a new %0 pattern

--EXPECTF--
string(20) "Some error %0 message"

This creates zero BC breaks, allows extensions to continue working just
fine with raw nulls or update to use %0 if they'd like, and creates no
ambiguities.

-Sara





Re: [PHP-DEV] Escape \0 in var_dump() output


2021-05-27

Thread
Sara Golemon

On Thu, May 27, 2021 at 8:42 AM Nikita Popov  wrote:

> The most prudent and BC-safe thing would be to add another function
>> `var_dump_escaped()` or even to prefer/advise json_encode() when content
>> safety is relevant, but additional type information is not (most of the
>> uses of var_dump we have).  Unfortunately, this doesn't actually fix the
>> initial problem you stated, which is just getting useful data out of CI
>> failures.
>>
>
> Well, we had https://wiki.php.net/rfc/readable_var_representation a few
> weeks ago, which is basically a better var_dump() with escaping and all --
> but you can tell how it went ;)
>
>

I don't specifically remember that thread, but suddenly I feel like I can
guess everything I need to know about the outcome. :(


Rather than change the output at all, why not just have a post-process step
>> in our test runner that transforms the output in the test report?  Then we
>> could be as aggressive as we want, going as far as escaping all
>> non-printables plus backslash since at that point we're in it for the human
>> readability (and knowing specific byte sequences is essential) and we break
>> zero BC for anyone else?
>>
>
> Transforming the test output (such that the transformed output is checked
> in EXPECT) would indeed be a way to address the original motivation.
> There's two caveats though:
> 1. It does not address the issue for other uses of var_dump(). People
> being confused by var_dump((array) $object) output because of the null
> bytes in the property names is practically a PHP classic. Of course, fixing
> this would take away from the authentic PHP experience :)
>

True, but neither (IMO) would just escaping null byte, which again I regard
as a half-measure.  It has all the negative impact of breaking BC (your
point about extension phpts is a good one), without going far enough to
address the human-readability problem for many common cases (CR/NL chief
among them).

Insert Karate Kid "squash like a bug" reference here.  Escape it all, or
escape none of it.


> 2. Changes to run-tests.php behavior also affect extensions, and I think
> this kind of change would be even harder to address for PECL extensions
> than a simple var_dump() behavior change (where you can at least easily
> fork two versions of the file for the tests that need it).
>
>
Would it? The report at the end of the run is for human eyes, generally
speaking.   A human can interpret escaping (or not) as needed.
Also, we could make the post-processing optional.

run-test.php --escape-test-output

Then we use that mode in CI where we need git-friendly diffs, and it works
"normally" elsewhere.

-Sara





Re: [PHP-DEV] Escape \0 in var_dump() output


2021-05-27

Thread
Sara Golemon

On Thu, May 27, 2021 at 5:44 AM Nikita Popov  wrote:

> https://github.com/php/php-src/pull/7059 does a surgical change to replace
> null bytes with \0.
>
>
Before delving into any other observations, I first want to state
emphatically that we should not ONLY escape chr(0).  We either apply full
on addcslashes() (or similar) or do nothing at all.  Half-escaped is worse
than not escaped.  Sadly, this presents more BC issues than just chr(0) or
'\\0' do alone since there are many more potential places where output will
change for anyone using it programmatically.

So should we?

On the one hand: The intent of the var_dump() function is for human
readable debugging.  Anyone using this in a programmatic way is Doing It
Wrong™, so I'm not too fussed about changing the output of this function.
On the other hand: WE use this function programmatically in our tests
across many thousands of occurrences.  Others probably rightly do as well.
Yes, the dissonance is real.

The most prudent and BC-safe thing would be to add another function
`var_dump_escaped()` or even to prefer/advise json_encode() when content
safety is relevant, but additional type information is not (most of the
uses of var_dump we have).  Unfortunately, this doesn't actually fix the
initial problem you stated, which is just getting useful data out of CI
failures.

The PR you offered is the lightest touch and fixes the issue you cited
without causing any likely damage to current users, but I don't think we
should ignore the ambiguity of the output.  Additionally, I think I could
make an easy argument in favor of escaping CR and NL at the very least.  At
this point the urge to escape backslash is extra-real as with windows paths
an innocent \n is far more likely.

--

Actually. Maybe we're thinking of this wrong.

Rather than change the output at all, why not just have a post-process step
in our test runner that transforms the output in the test report?  Then we
could be as aggressive as we want, going as far as escaping all
non-printables plus backslash since at that point we're in it for the human
readability (and knowing specific byte sequences is essential) and we break
zero BC for anyone else?

-Sara





Re: [PHP-DEV] A little syntactic sugar on array_* function calls?


2021-05-26

Thread
Sara Golemon

On Wed, May 26, 2021 at 2:36 PM Mike Schinkel  wrote:

> On May 26, 2021, at 2:34 PM, Sara Golemon  wrote:
>
>
> What I don't like about the specific proposal is that it's just a little
> too magic in its function selection and argument mapping.  There's also the
> fact that it doesn't leave room to improve specifics about the
> implementations of the methods.  I'd much rather seen an `Array` class
> defined with specific methods declared on it.
>
>
> Wouldn't an `Array` class necessarily result in array-incompatible
> pass-by-reference semantics, which is one of the same issues with userland
> using ArrayObject as an array replacement?
>
>
It would if the Array objects got returned.  I'm instead picturing an
instance that magically comes into being solely for the duration of the
method call.  Once the method returns, the object vanishes.

-Sara





Re: [PHP-DEV] A little syntactic sugar on array_* function calls?


2021-05-26

Thread
Sara Golemon

On Tue, May 25, 2021 at 4:20 AM Karoly Negyesi  wrote:
> I was wondering whether $array->map($somefunction) would be possible. I am
> not a C programmer by any stretch but reading ZEND_VM_HOT_OBJ_HANDLER(112
> it seems to me it should be quite easy (famous last words) to find out if
> object is an array and if so then
>
> 1. prepend the string array_ before the method name
> 2. based on a small lookup table move the "object" to the right place --
> either first argument or second.
> 3. do a function call instead of a method call.
>

While I don't love the specifics of the proposal, I am 100% in favor of
allowing arrays to be used in an object-like fashion.

What I don't like about the specific proposal is that it's just a little
too magic in its function selection and argument mapping.  There's also the
fact that it doesn't leave room to improve specifics about the
implementations of the methods.  I'd much rather seen an `Array` class
defined with specific methods declared on it.  In many cases these will be
simple trampolines to an existing function, but it gives us
self-documenting stubs and room to wiggle out of poor decisions from the
1990s.  Such a class would not be instantiable or inheritable, it would
just exist as a lightweight ValueObject for performing the method
invocations (we can make it internally instantiable using tricks like not
calling a private constructor).

Then some hand-wavey details about maybe returning objects which have a
cast-to-array handler, mumble mumble, devil in the details... waving
hands...

-Sara





Re: [PHP-DEV] Disable autovivification on false


2021-05-25

Thread
Sara Golemon

On Tue, May 25, 2021 at 11:23 AM Kamil Tekiela  wrote:

> I'd like to start a discussion on the following RFC
> https://wiki.php.net/rfc/autovivification_false
> Particularly, I am looking for opinions on whether this behaviour should be
> left alone, should be disabled on false, or should be disabled on null and
> false, and left only for undefined variables.
>
> Autovivification is very useful in PHP, especially with multidimensional
> arrays and loops. However, the question is should we allow it on false and
> null values going forward.
>
>
I agree it's useful, and should 100% not be killed on undef.  There is
doubtless a mountain of code in WordPress plugins alone which relies on
this, not to mention other frameworks and libraries.

As for `false` and `null`, I think it's reasonable to kill these (with a
deprecation period) in a major version (e.g. 9.0).  It might also be
reasonable to only kill this behavior when strict_types is enabled.
Essentially it would enforce making the array type accessors strict about
operating on arrays.  Would still need a deprecation period to go with
that, but it would be less-rough on migrations of legacy codebases.

-Sara





[PHP-DEV] PHP 8.0.7RC1 Available for testing


2021-05-20

Thread
Sara Golemon

PHP 8.0.7RC1 has just been released and can be downloaded from:
https://downloads.php.net/~pollita/
Or use the git tag: php-8.0.7RC1

Windows binaries are available at https://windows.php.net/qa#php-8.0

Please test it carefully, and report any bugs in the bug system:
https://bugs.php.net
8.0.7 should be expected in 2 weeks, i.e. on June 3rd 2021.

Hash values and PGP signatures can be found below or at:
https://gist.github.com/sgolemon/2e5c7a9d497fda62e10f6a76db43e490

Thank you, and happy testing!

Regards,
Gabriel Caruso & Sara Golemon

php-8.0.7RC1.tar.gz
SHA256 hash:
d93e1f26cce090119fe43645da9f2493c720ce85d6744965fda143a5e7cdd416
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcgbKEADZBrs4j2azo4r4UheuhAmIYSqn9ey5N2Ea
+bwwR0hGXwofxZloBouviVsJbtHpdAqPNToiPGi1xYMrWE21NvN7rqZOFtF3MMhv
qlS/ziNTk45Q1q1fo7vJDNi8LjpP6VIVfAZYkfKvp0HSSca/DR+7S1I72rRQlVUp
o/3j+ZI8ZbH8kCzcqQ1FAKNHlwF+eR6sdi4ge0g7TIk0GkMmUuucTTjA+FzLZVk/
J/RVyUY9Gbr082feL4Oe5zxVM6pv3EzUfUnUCepyMPhsyE0YTI7ws61qtv9JuncQ
OMRp/xK2wIFs/VxmPXrg673iojCZFjugG0Q4BASpXfTN07MB1mCJoerMc8HxwZbH
qA39HHOyRUcqlzJm6OE2XPemg7swD2tuW/oaTSX6RWKLgr9biskrBA5v1znlxJ5P
+0Lv5ips8sT6ONf+p3rgwGO9byPMUi6N6U7zzKnZ9UswGsloK0xxFBm5G+pl8AVb
tC1DjUPDMK8bcZ57cUkNuqOtukPAhu6BRVpkQ+1xogQLMvpMxIkHPvtX+MQ9w6Lf
EtPr2FHPDqGF1UvCcTcCM6qDArYvpJab8JjmzR+Hsq0B6j1hA1XZPSovcZzUuR6Q
G9OH/0AyuHQlPU0ZhVjqy5JiZitvPvlAxwimmuvvBrBQa6UI4ViDZVbLyV2bKOlQ
W5YLzg3MUQ==
=TW/v
-END PGP SIGNATURE-

php-8.0.7RC1.tar.bz2
SHA256 hash:
3e114755059c204af29a2f1044f7001ce42773ae10f5d6657b730ee11356b1d2
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhchOOEACo7tUxZHFodvS8N0jCBskTTWzaUrEe3w6H
ez0pDBMfLng8CzS1sOed5MPY5p1AIttQMlLvWciUKK4ru328LoaJXrKfdIh4sGfH
13Tg1WS6ELdC+nQw5S05F7FxxqtD9w9czMeHbAoBReB0f3YcqtoCsyPhV92t1AeK
opb3NWjpuuXbSBjXadYMLGtryeYtzUHR0b8dsXIFPHqNSDIIa/N3kEFkbiAe0znQ
8cdjdmd32gTdlZ40akHQ/AX648VhpBtotl/OV96wB9UreuflbDeueidQvukQu0Ab
lDKelR9q6OKa9HvB1zfMt11hrc0oDL0Dnlz06jeZMjQU6sCCEKbyIZ6FYuwB7GtY
tN+LtZbf68beyMUk6y9lubB+mej8HQqeClXXxTX3dGWC6EIdlrj4W4RJ0u++ZDqE
RG0kI4acqX6+rj2p8H1LxxZoSxWclsjZUYWFVyyRRNUstbSEroOM5OLSLoRGEQjf
Cf/UmsUh2IgBj1V70IFvny6u8VXsjWSyavs+uv5ZwtGwtHyu2NoH30ThD3lLuAoX
BArrQYb6+MPhJumYnnvTWit+nLYRqljRK11i3WNztyHUj5NswU5joNBEbRS8kZhO
0Prgku3lY9sc0lNJds/XurpFeB55qgIeuvzXaVOoXp4S4e+xyAWYE7Mkm8MEeB6V
BbrWxnmaMQ==
=/wdh
-END PGP SIGNATURE-

php-8.0.7RC1.tar.xz
SHA256 hash:
86371e7cf3d9bb3831b68d0615aa3c6a989554022096c63c8f7eefd3b5c43575
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmClU7cQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckiPD/9rgOrqxuscO/R787ckNEZFazAZQbaXtFs9
oaojKOqcrHoJOsxWJRvrq6syuUuDsNpJuxRN6pfzuTwhgTHxorv7ZjGiSwBt8Gdj
s5cFROkrxr4fJY/H2o941V839T73cq2h6sb/5y2TEHWxm8DoJq5wI5jGXfUtr0Kw
a0VzQ7pfhojFj+tONz4TMz4Gty5nIz/iQ8uzm4gLf7foruEU23mffTFHFeNSS3ox
hZhq5JeCuuo8oyz7Lfd3ZXW+09Vu5w/plspqa8kL9BDn60aOVJC5f/vKDLSzVuvd
wJ/IMl8LAUAAQZuCJZ7F6USk8AU07ksUwGvzqXUbB9rThJTeApb4c0YQ5uV2Gvkf
+NAN6eMSN/PwUpwyUO/9tB041osBG/nH6Zz8hU/Lejo9bPSG/xQEozg9gR0zwUPJ
g0YdUCLnGhB47vG9B44ptcVcU1Hht0jK5VjQuVtkbVKkih7Tboi05w3sZdjuyM7K
z6TI3yJBmC+0QvFk6DPgo1JJCnA4Hu+tfGYq617bkWqJv3cH5sbgU111yOL9Xlf0
KZUX+D4CT4YrtEYRA/Xl9lwR+PgcWX3Z8FUOMBTquUYYIiHcj10PD56At5nf/teT
iBk/lqlsu5Gajhh8Sm4/G60Bdb/exZw35s3arE+S1roKC0Z6CSEtGP+je+XIp5cr
fE8xYaIYZw==
=ZIq+
-END PGP SIGNATURE-





Re: [PHP-DEV] [RFC] Partial function application


2021-05-13

Thread
Sara Golemon

On Thu, May 13, 2021 at 2:31 PM Andreas Hennings 
wrote:

> 1. Serializing:
> But outside of the above cases it should be technically possible, or not?
>
>
I suspect that the limitations you cite make any kind of general
serializing both unreliable and impractical.  I wouldn't plan on meaningful
serialization.


> 2. var_export()
>
>
Same as above, really.


3. Parameter switching
>
> Could we express the following as a partial function?
>
> static function ($a, $b) {return foo($b, $a);}
>
> E.g. as foo(?1, ?0) ?
>
>
Using named parameter we can:

foo(b: ?, a: ?);

-Sara





Re: [PHP-DEV] Could we drop the bottom-posting rule?


2021-05-11

Thread
Sara Golemon

On Tue, May 11, 2021 at 9:21 AM Chase Peeler  wrote:
> On Tue, May 11, 2021 at 2:34 AM Mel Dafert  wrote:
> > (Gmail certainly can't, it can't even send non-HTML mails, and even with
> > K-9 I have to remember doing it.)
> >
> I’m sending this from gmail on my phone, so not sure what you are talking
> about.
>

This plaintext reply sent via Gmail web client. I don't know what Mel is
talking about either.

-Sara





Re: [PHP-DEV] [RFC][Draft] Body-less __construct


2021-05-11

Thread
Sara Golemon

On Tue, May 11, 2021 at 5:18 AM Matīss Treinis  wrote:
> Yes, just to clarify the scope of my initial proposal, this should only
> ever apply to promoted constructors that have 1 or more promoted
> parameters, and no not-promoted parameters.
>

Hard disagree. While it's certainly silly/pointless to have a nil
constructor when there are non-promoted args present, I think that
deliberately making that mode special (read: inconsistent) is the wrong way
to go.

> These would NOT be considered valid:
> public function __construct();
>

For example, Niki's reply showed a place where that mode is perfectly
reasonable (singleton finals).  If you must have this syntactic sugar, then
please make it consistent.

> as well as anything not related to __construct.
>

I'd be willing to go along with inconsistency since once you allow syntax
you can't unallow it without pain. So while I don't love the tack, I'll
follow it if we do this feature. (which IMO we shouldn't).



On Tue, May 11, 2021 at 8:59 AM Matīss Treinis  wrote:
> If there are no super strong arguments on why this should not happen or go
> to RFC, I will draft a RFC and from there, the usual process applies.
>

I think you've heard a number of strong arguments why it should not happen,
but I also think this deserves its chance to be fleshed out and voted on,
so by all means, do work the RFC.

-Sara





Re: [PHP-DEV] [RFC] Deprecate ticks


2021-05-11

Thread
Sara Golemon

On Tue, May 11, 2021 at 3:53 AM Nikita Popov  wrote:

> I'd like to propose the depreciation of the ticks mechanism:
> https://wiki.php.net/rfc/deprecate_ticks
>
> I'm submitting this separately from the PHP 8.1 deprecations RFC, as this
> is a language change, even if not a particularly important one...
>
>
I came here to plea for the poor, disrespected ticks function.
Then I went to github and asked who was using it...
In the 10,000 results which came up for that string in actual PHP code, I
paged through the first 20% (2000) cases.
They were ALL either a phpt test file, or an auto-generated proxy function
(which appears to not actually have any uses).

So yeah.  Pour one out for ol' ticks.  May it rest in peace (following a
suitable deprecation period leading up to PHP 9.0).

-Sara





Re: [PHP-DEV] Could we drop the bottom-posting rule?


2021-05-11

Thread
Sara Golemon

-1. Top posting encourages lazy email composition. One should put an ounce
of thought into how one organizes a response.

On Mon, May 10, 2021 at 4:52 PM Kamil Tekiela  wrote:
>
> Hi Internals,
>
> Could we drop the bottom-posting rule?
>
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's
really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients
defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
>
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
>
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
>
> Regards,
> Kamil





Re: [PHP-DEV] [RFC][Draft] Body-less __construct


2021-05-10

Thread
Sara Golemon

On Mon, May 10, 2021 at 3:56 AM Marco Pivetta  wrote:

> > Another point to be made here, as far as my interpretation of PSR-12, the
> > curly braces occupy two lines for methods with multiline arguments. So
> for
> > whoever follows PSR-12, it's more like this, with brackets just dangling
> > there across 2 lines.
> >
>
> Given that:
>
>  * `{}` can already represent what you want
>  * the issue is more of a coding-style related topic
>
> I suggest bringing this up in a new PSR instead. Consider that PSR-1, PSR-2
> and PSR-12 were designed pre-PHP-8, so they will need adjustments again,
> but AFAIK nothing has moved yet, since the ecosystem is still adapting to
> the PHP 8 changes (I myself haven't finished adopting it on many of my
> libraries).
>
>
A whole lot of agreeing with Marco here.  The problem is the coding
standard, not the syntax.

Also, as Guilliam said in a later reply, using semicolon already has a
meaning and this contradicts that.  Let's not make the syntax more
confusing purely to avoid updating a PSR that was meant to be a living
standard.

-Sara





[PHP-DEV] PHP 8.0.6 released


2021-05-07

Thread
Sara Golemon

The PHP development team announces the immediate availability of PHP
8.0.6. This release reverts a bug related to PDO_pgsql that was
introduced in PHP 8.0.5.

PHP 8.0 users that use PDO_pgsql are encouraged to upgrade to this version

For source downloads of PHP 8.0.6 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_0_6.php
Downloads: https://php.net/downloads
Windows downloads:  https://windows.php.net/download#php-8.0
Changelog: https://php.net/ChangeLog-8.php#8.0.6
Release Manifest:
https://gist.github.com/sgolemon/a5b173900bac5e5f22529cec7d2fdcf4

Many thanks to all the contributors and supporters!

Gabriel Caruso & Sara Golemon

php-8.0.6.tar.gz
SHA256 hash:
51a3dcea6deb8ab82ad035d15baa7f5398980f576ac1968313ef149f7cf20100
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmCRiTUQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhck5oEACfJ38ZdPSJ1Z3dCNEB7rKquPS2mmWaGcuM
LFzMPlxie43xMyG3R7nRhYft9RjeuAZ48BKqJWBdmG/YXhYnnTUMjp5Cfj1IWfJ1
zPOxn4iumRX1hPue627V88iI1MRIS4y2+NxmgYR7Ughbq1m0p1OGgh22var0/1ZF
GzNTGhQ7yQKzJyDXzEg0EjPr32dPuA5pm9XVGqbppXHKkGQFxkIH0KPa+3noepwy
SE9Bstfg3myTq0yeXIzlX0u9dmcmro5sx6swELez6LRcvR4M5HwcWtOxdE4hSzLJ
Xg+lNkT02BYyVXfa4GPnMhe01Q7mKrU91Ke+Fhqor9bZWvIS75m+NrPGtunzhGUz
EqSiMiSVTg4HvbRE0byXWxh/fAZwaYsmGam4mPm0+lncNyU27g50FmXjJmE+7plL
VXo/bfKBgAtQgkDVpM+dyq2I5biQo2jvukD2BUWtmEYz3EGnuIKjCLy4We/hxgsi
eEvyhMuXyOLI/4CZUUPGu/2j6oRGsFtFuwHIuPaRs/66StFg/v2ySDRZD/I1Xc5C
LStH2MTUpdo1wyVFgO/R8t5zn+MkOpdNaiwlVtRak7upHY37hwqcw7NLCscGEpZU
dJjCUfL+dP219rc4RsmtM4hyd4qCVxS5IYvLPR5IiJU3jOTxD1SGRgzBB+HDQ3RS
oy6UwqFYZg==
=Chc3
-END PGP SIGNATURE-

php-8.0.6.tar.bz2
SHA256 hash:
26a8a9dad66012039deb0bcf151c6e22ab1e4b6a91508383ff705da41289526e
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmCRiTgQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhckC7D/9SvFISJYm0qPSA6L3g6fQaBpuS/1a1HTqn
2Fcu/42t5CvIExUUdPrm+c6ssIYbldWAU97Tl0A0uP0Gs578G8xel4wsXsOWKwxn
/rqEG2bRcI8qwaCpDy1ytKVX1IB5yynFrgCZrunYfU/E3Xg1n2KYlcRNDisgyw/E
Z+u0RqVmIKKwRtDcx3zEGFq+alKSWV+jorAnovx/b4P8f0X/Z8SsxwXgIcs8+aXh
yFmCDzyQq+d/XQ1mTWMDIcu+OOEJcnCTRlYRUAgmc/ofFRm+CVCeh1aMnSxcQk7x
clFGPJFaXVUkiEa3twehfWe9+5wJLbjMnmujqG2LTe/drPorkmim7Ce0LUhvPwFj
GW6AyngZH8R3XAxo3meCZanpkGBgPVIqdBj6IMa2ZnihfUKCyUOrNLKmiyrjWVDR
y8EUJbsfRb54m3b+Xhh5VzBkpLA1Bgw/yTy8c5SY/+zbxoRXz9FQRjFRq3cjYV11
UEWr9M8MsXzKvpVXNrFKBfU374Yuz/3c5YR0m9k8LXehpALq9pKdvUKkoZqDXHSF
lIK9cR22fiyIcxNK/ZNXwrk1MDLrSRCRTFhrtn5VrG4dRjzLD+0W4NNjR5BrexW0
YOpyQyhAbOVv6LHFgLUBSLdk0vkln6rQL+TAWDYB9rEneGgZsVjXIL63kebY2H3C
tyXTX/RzCg==
=AccQ
-END PGP SIGNATURE-

php-8.0.6.tar.xz
SHA256 hash:
e9871d3b6c391fe9e89f86f6334852dcc10eeaaa8d5565beb8436e7f0cf30e20
PGP signature:
-BEGIN PGP SIGNATURE-

iQJEBAABCgAuFiEEFyn4OTjaROJ7oPTT29s5dHDRIXIFAmCRiTgQHHBvbGxpdGFA
cGhwLm5ldAAKCRDb2zl0cNEhcqh5EACrNWU0/Ve4VFbJY+GKOhANTyeDbyol6fWv
fKXWLAhi5w7CLIY/GojH2TtxifU8kyIbuOj+9D9kblrnplTfPhtJrxfyXSGu+HQr
qML3xpPs++fqSdw5kj2ninqQAh0+OZAOgDTAO/r1eS1eaU1glDCzan57IiOsvp7c
0ZxhztCshjZ8DvkLjz1AfQUOXWZAS9DQE7p6ZPJC3jnc6DtfPsj1YSaovGjJ6dC0
e4dFUk/fluD2UmyBgPrUcuBYCnF3Gyd64NP8zTveY1SnrvNBIIqEBcCLbCfYxjwY
HyLa7T+Ht14XWUqmi8LAAD+Z9OFuuX13UUpkeQHO/5VmPEWQBH+ggogx2yUpwNGj
WSfyZLUtavFngWxu7H7k2FZI8CUwXR79tW+mhe/viFKKNwOExRJNTAb+EY7BvtbP
C/nTGJOfNNKJH6qaWXdka3LUVFrCMmJzskhCga8P4pKxhqx/PwzHGDM8XJ94Bn6j
WHWsnqYJfIFLPm1LtGAHAqNcu4Rtp2jnKT4RC4I9Kq9RVBy038qMV9Og1zJbKTLm
xJDicYBQbG/rPKgI59zI3BFTPA2VBmV9qULVzJi+kExZMgTqiAMkBHeNIMZN61vo
MF2DrnobMaERu1yUnbQjcf/kNvpC7mASnLIo9j+kUM3QI7mAHJCSUEjktEaCE/jj
PA1Xa3nsUQ==
=xz28
-END PGP SIGNATURE-





Re: [PHP-DEV] PHP Language Specification


2021-05-06

Thread
Sara Golemon

On Thu, May 6, 2021 at 10:10 AM Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> czw., 6 maj 2021, 16:01 użytkownik Christoph M. Becker 
> napisał:
>
> > I wonder what to do with the PHP Language Specification[1].  Apparently,
> > the repo is abandoned (last commit was more than a year ago, although
> > PHP 8 changed quite some stuff).  If we don't have the bandwidth to
> > maintain it, we should mark it as unmaintained, and maybe some of the
> > information could be moved to the PHP manual  (I quite like the strict
> > syntax specification, which the manual almost completely lacks).
> >
>
> How much effort would it require?
> Is there potentially someone who could help with reviews?
>
>
Which part? Getting it up to date and keeping it there? Or moving the parts
we most care about to the manual then abandoning it?

I'm actually fairly happy either way, but it does need some TLC.  Some
brave soul to step up and yes, "YES! I WILL DEFEND THE LANGUAGE
SPECIFICATION!"  Someone with the courage to do the dirty work.  WHO WILL
STAND AND FIGHT?!*

-Sara

* I just got my second dose of the vaccine and evidently it's making me a
bit goofy, but don't let that stop anyone from stepping up.  We all make
PHP better together.





[PHP-DEV] Re: [8.1] Release Manager Voting Opens


2021-04-26

Thread
Sara Golemon

On Mon, Apr 12, 2021 at 2:40 PM Sara Golemon  wrote:

> Please take your newly reset authentication credentials over to
> https://wiki.php.net/todo/php81 and place your ranked votes.
>
>
The voting for PHP 8.1 Release Managers has now closed.

In the first round, both Ben Ramsey and Patrick Allaert handily captured a
quota of votes to secure seats meaning that 2nd and further rounds do not
need to be considered and we have our results.

The Veteran RM for 8.1 will be Joe Watkins.
The Rookie RMs for 8.1 will be Ben Ramsey and Patrick Allaert.

Congratulations to Joe, Ben, and Patrick, and a big thank you to all who
volunteered to step up and assist with this essential role.

Please refer to
https://github.com/php/php-src/blob/master/docs/release-process.md#new-release-manager-checklist
for tips on getting permissions and other pre-release tasks.
And of course, reach out to the RM list and/or individual prior release
managers at any time for help.

-Sara





Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT


2021-04-23

Thread
Sara Golemon

On Fri, Apr 23, 2021 at 2:41 PM Niklas Keller  wrote:

> People might remember the approach incorrectly or have a similar idea
> themselves and make mistakes in their own version of such code.
>
>
While I agree in principle that this is possibly true and a good
justification for adding guard rails, I have to admit that assumptions are
only assumptions, they're not data.  If this pattern is to be used as
evidence of a problem, then citations are required.

-Sara





Re: [PHP-DEV] Binary (un)safety of password_hash() used with PASSWORD_BCRYPT


2021-04-23

Thread
Sara Golemon

On Fri, Apr 23, 2021 at 2:56 PM Kamil Tekiela  wrote:

> We can also consider switching the default to Argon2id.
> As Scott says the NUL byte truncation is not a bug in PHP, but a bug in
> the algorithm. I don't know the exact specification but maybe we should
> leave the current implementation as is?
>

The only way we can make argon2i(d) into the default is if it's always
available.
Currently, the only implementations we have are from external (non-system)
libraries, and making those libraries required is essentially a non-starter.

-Sara





[PHP-DEV] Re: [8.1] Release Manager Voting Opens


2021-04-23

Thread
Sara Golemon

On Mon, Apr 12, 2021 at 2:40 PM Sara Golemon  wrote:

> As stated last week, the vote for your PHP 8.1 Release Managers opens
> today.
>
> Now, if fact.
>
> Please take your newly reset authentication credentials over to
> https://wiki.php.net/todo/php81 and place your ranked votes.
>
>
A quick reminder about RM voting.  We've got 27 votes so far, but I know
there are more folks active.  The voting period ends on Monday April 26th.
I hadn't set a time, but let's call it 14:40 America/Chicago (UTC-0500)
since I opened it at that time on the 12th.

Again, best of luck to the candidates, and looking forward to a smooth and
successful PHP 8.1 release.

-Sara




    
  1   2   3   4   5   6   7   8   9   10    >  
  
  

    

      
    
    
 1 - 100 of 1464 matches
    

    
Advanced search


Search the list




    
    

      

                               Site Navigation
      
      

        
The Mail Archive home
        

          internals - all messages
        

          internals  - about the list
        
Expand
      
    

    

      

  				Mail list logo