Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
> On Feb 25, 2025, at 09:55, ignace nyamagana butera > wrote: > > The problem with your suggestion is that the specification from WHATWG and > RFC3986/3987 are so different and that the function you are proposing won't > be able to cover the outcome correctly (ie give the developper all the needed > information). This is why, for instance, Maté added the getRaw* method > alongside the normalized getter (method without the Raw prefix). The two functions need not return an identical array of components; e.g., the 3986 parsing function might return an array much like parse_url() does now, and the WHATWG function might return a completely different array of components (one that includes the normalized and/or raw components). All of this is to say that the parsing functionality does not have to be in an object to be useful *both* to the internal API *and* to userland. Recall that I'm responding at least in part to the comment that "Considering that one of the other stated goals of this RFC is to provide this API to other core extensions, the previous objections [to the Request/Response objects going into core] do not apply here." If the only reason they don't apply is that the core extensions need a parsing API, that reason becomes obviated by using just functions for the parsing elements. Unless I'm missing something; happy to hear what that might be. -- pmj
Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Hi there, > On Feb 24, 2025, at 03:36, Tim Düsterhus wrote: > ... > > but had a look at the “after-action summary” thread and specifically Côme’s > response, which you apparently agreed with: > >> My take on that is more that functionality in core needs to be «perfect», or >> at least near unanimous. Côme Chilliet's full quote goes on to say "And of course it’s way easier to find a solution which pleases everyone when it’s for something quite simple" -- the example was of `str_contains()`. > Or perhaps phrased differently, like I did just a few days ago in: > https://externals.io/message/126350#126355 > >> The type of functionality that is nowadays added to PHP’s standard library >> is “building block” functionality: Functions that a userland developer would >> commonly need in their custom library or application. > > *Correctly* processing URIs is a common need for developers and it’s > complicated to do right, thus it qualifies as a “building block”. Agreed. Add to that: > On Feb 23, 2025, at 18:48, Gina P. Banyard wrote: > > Considering that one of the other stated goals of this RFC is to provide this > API to other core extensions, the previous objections do not apply here. (The previous objections being that this ought to be left in userland.) * * * I'm repeatedly on record as saying that PHP, as a web-centric language, ought to have more web-centric objects available in core. A _Request_ would be one of those; a _Response_ another; and as being discussed here, a _Url_. However, if it is true that ... - "it’s way easier to find a solution which pleases everyone when it’s for something quite simple" - "The type of functionality that is nowadays added to PHP’s standard library is “building block” functionality: Functions that a userland developer would commonly need in their custom library or application." - "one of the other stated goals of this RFC is to provide this API to other core extensions" - "Parsing is the single most important operation to use with URIs where a URI string is decomposed into multiple components during the process." (from the RFC) ... then an extensive set of objects and exceptions is not strictly necessary. Something like `function parse_url_whatwg(string $url_string, ?string $base_url = null) : array`, with an array of returned components, would meet all of those needs. Similarly, something like a `function parse_url_rfc3986(string $uri_string, ?string $base_url = null) : array` does the same for RFC 3986 parsing. Those things combined provide solid parsing functionality to userland, and make that parsing functionality available to other core extensions. -- pmj
Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API
Hi all, In earlier discussions on the [Server-Side Request and Response objects](https://externals.io/message/108436) RFC and the [after-action sumamry](https://externals.io/message/109563), one of the common non-technical objections was that it would better be handled in userland. Seeing as there are at least two other WHATWG-URL projects in userland now ... - https://packagist.org/packages/rowbot/url - https://packagist.org/packages/esperecyan/url ... does the same objection continue to hold? -- pmj
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
Hi Rowan and all, I apologize in advance for the wall-of-text; the short questions lead to long answers. > On Jan 2, 2021, at 12:56, Rowan Tommins wrote: > > On 01/01/2021 20:31, Paul M. Jones wrote: > >> The complaints against the incomplete and inconsistent immutability of PSR-7 >> have merit. > > The big mistake of PSR-7, in my view, is mixing immutable objects with > streams, which are inherently mutable/stateful. (/me nods along) Streams were noted as the one explicit exception to immutability in PSR-7. Looking back on it, that should have been a sign to us that immutability should not have been a goal. (Re: PSR-7 but not re: immutability, there is at least one more mistake born of the original intent, that seemed reasonable at the time but in hindsight was another poor decision: it combines the concerns of the HTTP message with the concerns of middleware communication. This observation is attributable to [deleted] at Reddit ... https://www.reddit.com/r/PHP/comments/5ojqr0/q_how_many_psr7_implementations_exist_a_zero/dcjxtxl/ ... stating "[T]he true intent of PSR-7 [is] not to be an HTTP message standard, but to be middleware IO standard, which happens to be mostly (but not only) an HTTP message." It's an accurate assessment.) > I wonder if there are any lessons to be learned there in terms of what kinds > of immutability the language should encourage / make easy. I think there are; I wrote about at least some of them here ... https://paul-m-jones.com/post/2016/09/06/avoiding-quasi-immutable-objects-in-php/ ... in which I conclude that, if you want to build a truly immutable object in PHP, it appears the best approach is the following: - Default to using only scalars and nulls as properties. - Avoid streams as properties; if a property must be a stream, make sure that it is read-only, and that its state is restored each time it is used. - Avoid objects as properties; if a property must be an object, make sure that object is itself immutable. - Especially avoid arrays as properties; use only with extreme caution and care. - Implement __set() to disallow setting of undefined properties. - Possibly implement __unset() to warn that the object is immutable. I put those conclusions (and other resulting from that article) into an implementation described here: http://paul-m-jones.com/post/2019/02/04/immutability-package-for-php/ > is it better to constrain entire objects to be immutable rather than > individual properties? I would say that the entire object ought to be immutable, for reasons that are difficult for me to articulate. > And should there be restrictions on what you can declare as immutable, since > "immutable resource" is largely nonsensical? I think so, and I note some of those restrictions above. In particular, the immutability package ValueObject further inspects arrays to restrict their values to immutables as well. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals
> On Jan 1, 2021, at 13:14, Larry Garfield wrote: > >> The web dev discourse is one-sided with regard to immutability, > > Yes, if you've heard any of the regular whining about PSR-7 being an > immutable object you'd think it's one-sided in favor of mutability. To characterize it as "whining" is pretentious. The complaints against the incomplete and inconsistent immutability of PSR-7 have merit. As one of the sponsors of PSR-7, I have come to regard its quasi-immutability as one of its main weaknesses, one that we of FIG should have (but failed) to predict would be more trouble than it was worth. The fewer people who use it, the better. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Documentation is on git
> On Dec 30, 2020, at 08:19, Andreas Heigl wrote: > > Hey folks! > > The PHP-Documentation has moved to git! Absolutely phenomenal. Well done all around! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage
> On Dec 4, 2020, at 04:52, Nikita Popov wrote: > > Hi internals, > > I would like to propose the following RFC, which restricts certain rare > usages of $GLOBALS. This change will improve performance, reduce internal > implementation complexity, and fix a very large class of bugs relating to > $GLOBALS handling in internal functions. > > https://wiki.php.net/rfc/restrict_globals_usage > Big +1 -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Attribute Syntax Revote
Hi all, > On Aug 21, 2020, at 08:23, Benjamin Eberlei wrote: > > It was stopped and reset last week, because it was started too early. Ah, I see -- I received the message I quoted *after* I placed a vote yesterday, so I thought it had been reset *yet again*. Glad that I was wrong ... > I remember that you were one of the people to request this :-) ... but to be clear, I noted that the proper thing to do was to restart the two-week discussion period, thus resetting the time at which the vote could be held. Obviously that was not done. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
[PHP-DEV] Attribute Syntax Revote
Hi everyone -- 1. Did anyone else here get this message (below) from Derick yesterday? 2. Maybe I missed something -- why was the vote reset? > > From: Derick Rethans > Subject: Attribute Syntax Revote > Date: August 20, 2020 at 10:36:36 CDT > To: Derick Rethans > > Hi! > > I'm reaching out because you had voted in the "New Attribute Syntax > Choice" poll. This poll has been *reset* and your original vote has been > discarded. > > The vote has now been restarted, so please indicate your choice again, > if you have not done so yet: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting > > Please note that there are now 6 options. > > cheers, > Derick > -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
Hi all, > On Aug 15, 2020, at 18:27, kont...@beberlei.de wrote: > > The Voring RFC clearly states 2 weeks from the announcement on this list. Which rule was clearly not followed ... > If we consider the current vote an instance of human error ... which consideration I agree with ... > then i dont see how restarting the discussion helps. ... it helps by following the rule: the intervening vote disrupted the discussion, which now (to conform to the rule) should restart. > I spent the whole day incorporating every argument and discussion thread into > the new RFC Version to be, so that voters will be fully informed > by the RFC once the vote re-starts on Tuesday. I'm very glad to hear that; the vote should not re-start on Tuesday, though, since we'll need 2 weeks to discuss these important and substantial revisions. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
HI all, > On Aug 15, 2020, at 18:00, Benjamin Eberlei wrote: > > Additionally, Derick and I are waiting for word from Sara and Gabriel at > the moment, but we suggested to close and reset the vote to wait until the > discussion period is over on Tuesday to accommodate the criticism of us > prematurely starting the vote (by accident, not intentionally). /me furrows brow If I understand correctly, that means the currently-running vote overlaps with the discussion period? If so, that sounds (again) highly irregular. The proper thing to do here is a full reset: restart the 2-week discussion period at the moment the current vote is declared null and void, then start a new vote (if the RFC is not withdrawn) after thatn 2-week period. Basically, the sooner the current vote is explicitly declared null and avoid, the sooner the properly-conducted 2-week discussion period can begin. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> On Aug 15, 2020, at 04:54, Michał Marcin Brzuchalski > wrote: > > Currently you're the only one who wants to wipe the vote and there is no > much voices willing to follow your proposal. He's not alone. This whole re-vote on the attribute syntax has been highly irregular. This vote should be canceled, regarded as null and void; the RFC fully updated with the results of the discussion thus far, including all the notes provided by Theodore; a new 2-week pre-vote discussion initiated; and *then* a new vote can be initiated after that 2 week period. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> On Aug 14, 2020, at 09:16, Benjamin Eberlei wrote: > > What do you mean by defer exactly? Stop voting or reset the vote? We were > thinking of extending the vote until September 1st. For my part, "extending a vote that started too early to let it run longer" is not a reasonable remedy. The right thing to do here is not to try to salvage the time spent and thereby depart even further from normal conduct, but instead to stop the vote, declare it null and void, and restart a proper two-week pre-vote discussion period. (That presumes the need for the RFC even exists, which I submit it does not -- but that's a separate topic.) -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> On Aug 13, 2020, at 10:44, Theodore Brown wrote: > > Indeed, it looks like you are right. I missed that Joe withdrew his > RFC on August 2nd: https://externals.io/message/111218#111288. The > declined RFC can still be viewed via a past page revision. [1] > > Apparently Derick then authored a new proposal under the same wiki > URL and moved it under discussion on August 4th, with a request that > people submit patches for other syntax alternatives to include in the > vote. [2] So the first date this RFC could be eligible for voting is > Tuesday August 18th. So, a week+ early, then? Surely that means the current vote null and void, to be reset entirely following a proper discussion period -- one without concurrent voting. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> On Aug 12, 2020, at 10:25, Sara Golemon wrote: > > If others agree that it's premature, we can stop the vote, > but I'm not inclined to disrupt the process over such a small variance. It's premature. If we can't follow our own rules, why even have them? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
> On Aug 11, 2020, at 09:54, Sara Golemon wrote: > > On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote: > >> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting >> >> > Just chiming in to say all, y'all voting for @[...] are making a terrible > choice, and are you sure you're okay with it? Maybe -- but we can always vote *yet again* on this, until the voters *finally* get it right. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hi all, > On Aug 4, 2020, at 17:07, Pedro Magalhães wrote: > > I'd like to reinforce the idea that this RFC (as all RFCs) needs a Yes/No > primary vote which should attain a 2/3 majority to pass. As it was the case > with https://wiki.php.net/rfc/shorter_attribute_syntax, it had a primary > vote asking "Are you okay with re-voting on the attribute syntax for PHP > 8.0?" and that vote passed with 50 to 8. > > The primary vote on this RFC could be the exact same question, but I > believe the primary vote needs to be there. Without this primary vote, we > could be enacting a change that only (with 4 options) 25%+1 voters support, > which is clearly insufficient. However, if 2/3 of the voters agree that > something needs to change, they are also accepting that the change may not > be the one they prefer. Hear, hear. If this RFC *must* go to a vote (and that is not a given), then adding a primary vote along the lines of "Are you okay with re-voting on the attribute syntax for PHP 8.0?" would go a long way toward alleviating the "vote until the voters get it 'right'" problem. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi Michal, > On Jul 29, 2020, at 01:13, Michał Marcin Brzuchalski > wrote: > > Hi Paul, > > wt., 28 lip 2020 o 20:56 Paul M. Jones napisał(a): > >> ... >> Let's count. + is "change away from @@ to anything else", - is "stay with >> @@", ? is hard-to-tell/weak/uncertain/they-all-suck. >> ... >> Michal Brzuchalski: -? >> > > Wow. Hold on your horses. I was never in favour for @@ but always against > at least AFAIR. > Where did you get that? > > Anyway it should be ++ here Ah yes, clearly a mistake -- my apologies. > It's hard to rely fully on your statement considering such a mistake. I encourage you (and everyone sle who is interested!) to go back and check that Twitter thread to see if I have made other errors. In the absence of them, my conclusion still stands: that is, "the majority of Twitter respondents in that thread appear to be against @@, and in favor of 'something else'." -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 14:15, Ben Ramsey wrote: > >> On Jul 28, 2020, at 14:10, Paul M. Jones wrote: >> >>> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: >>> >>>> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >>>> >>>> Now, it may be that #[] or <<>> or something else actually is "better" in >>>> some sense that cannot be articulated. But if there are no existing >>>> technical hurdles to be overcome with the already-voted-on-and-accepted >>>> solution of @@, what technically compelling reason can there be to revote? >>> >>> >>> IMO, there is no compelling reason to revote other than the fact that we >>> have no process for what to do in this situation. >> >> What "situation" is this, exactly? AFICT we have a working implementation >> using @@, with no technical hurdles to surmount. Or have I missed something >> that now prevents @@ from working per its RFC? > > > The new RFC outlines reasons why `@@` is a sub-optimal choice. And yet it was the one chosen by the voting process. (Silly voters, making sub-optimal choices!) The rest of your message reveals what I thought was true: i.e., there are no currently-verified technical barriers to @@. To wit: > * current parser conflict (which can be worked around) AFAICT that pre-existing problem has been fixed, so this is a non-issue. > * possibility for further (as of yet unknown) parsing issues IOW, imaginary issues, aka FUD. > * a closing ] makes it easier to extend Attributes with more syntax, and at > the same time not be at the risk of running into parser conflicts Maybe, maybe not. This has the strongest possibility of becoming a technical argument, but no competing implementation (with a comparative implementation using @@) has been presented as an example. So as it stands now, this also is imaginary. > * userland analysis tools have difficulties parsing `@@` Though it does not seem insurmountable for those userland authors. Also, this is an interesting take: does Internals now defer to userland? If so, maybe it's time to open up voting more widely, so that the whole of userland can be represented more effectively here. Again, I don't especially care if @@, <<>>, or #[], or something else makes it through. Annotations of some sort seem like a nice idea, and I think they'd be of benefit. But if we are to make decisions by what is ostensibly a democratic process, we should stick to the voted decisions, instead of re-voting issues until the voters "get it right" according to some implicit and unstated criteria. (If re-voting over and over is the plan, I've got some RFCs I might like to revisit as well.) -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
> On Jul 28, 2020, at 14:07, Ben Ramsey wrote: > >> On Jul 28, 2020, at 13:55, Paul M. Jones wrote: >> >> Now, it may be that #[] or <<>> or something else actually is "better" in >> some sense that cannot be articulated. But if there are no existing >> technical hurdles to be overcome with the already-voted-on-and-accepted >> solution of @@, what technically compelling reason can there be to revote? > > > IMO, there is no compelling reason to revote other than the fact that we have > no process for what to do in this situation. What "situation" is this, exactly? AFICT we have a working implementation using @@, with no technical hurdles to surmount. Or have I missed something that now prevents @@ from working per its RFC? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change
Hi all, > On Jul 28, 2020, at 12:57, Theodore Brown wrote: > >> On Tue, July 28, 2020 at 9:46 AM Joe Ferguson wrote: >> >> ... >> >> Feedback to Derick's tweet >> (https://twitter.com/derickr/status/1285912223639130114) >> were [sic] overwhelmingly positive > > Are you sure? I took a look at the thread and it seems like the > responses were pretty mixed. Let's count. + is "change away from @@ to anything else", - is "stay with @@", ? is hard-to-tell/weak/uncertain/they-all-suck. Derick Rethans: ++ Rafael Dohms: +? Alexander Berl: -? Chris Emerson: -- Tamas Erdelyi: ?? Phili Weinke: ?? Trent: ++ Juriaan Ruitenberg: ++ Mehran: ++ Stephan Hochdorfer: ?? Cees-Jan Kiewiet: ?? Tom Witkowski: ++ Matiss: ++ Henry Paradiz: -- Saif: ?? Paul Redmond: ?? Marco Pivetta: ++ Simon Champion: ?? @eimihar: ?? Brent: +? Graham Campbell: +? Dmitri Goosens: ++ Sergej Kurakin: -? Francis Lavoie: ?? Michael Moravec: ?? John Hunt: ?? Lars Moelleken: ?? Michal Brzuchalski: -? Kyrre: ?? Steve MacDougall: ++ Agustin Gomes: ?? Mike Rockett: ++ Matias Navarro: ++ Marisa Clardy: ++ Warp Speed: -- WJB: +? Martijn Minnis: -- Dennis de Best: ?? Damo: ?? SOFTonSOFA: +? Ashish K. Poudel: +? Bastien Remy: ?? Matiss: +? Thierry D.: +? Ihor Vorotnov: ?? Hugo Alliaume: ?? Juan Millan: +? Olbaum: +? Steve Baumann: ?? James Mallison: ?? Marco Deleu: ?? TheGenuinenessSheriff: ++ Golgote: ?? ++: 13 definitely prefer changing to something other than @@ (though not necessarily #[]) +?: 10 probably prefer changing to something other than @@ (though not necessarily #[]) ??: 23 hard-to-tell/weak/uncertain/they-all-suck -?: 3 probably prefer to keep @@ --: 4 definitely prefer to keep @@ So, the majority of Twitter respondents in that thread appear to be against @@, and in favor of "something else" (24 to 7). Having pointed all that out, I note that Twitter is not the voting mechanism here. Further, I opine that "voting repeatedly until the voters get it 'right' and then calling the matter settled for all time" is not how decision-by-voting is supposed to work. Now, it may be that #[] or <<>> or something else actually is "better" in some sense that cannot be articulated. But if there are no existing technical hurdles to be overcome with the already-voted-on-and-accepted solution of @@, what technically compelling reason can there be to revote? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php
Re: [PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)
> On Apr 9, 2020, at 02:29, Côme Chilliet > wrote: > > Le mercredi 8 avril 2020, 07:35:10 CEST Paul M. Jones a écrit : > >> **Lesson:** Of functionality that can be accomplished in userland, only >> trivial/simple functionality is acceptable. > > My take on that is more that functionality in core needs to be «perfect», or > at least near unanimous. And of course it’s way easier to find a solution > which pleases everyone when it’s for something quite simple. Ah, yes, that latter sentence makes for a a subtle difference, and I think a fair one. Nicely said. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays
> On Apr 8, 2020, at 08:37, Derick Rethans wrote: > > I still believe that none of these options are needed. var_export() has > been added to generate PHP parser readable code. I think it was said earlier, but I'll say it again: having it generate parser-readable code is great, but having it optionally generate pleasantly-readable code (e.g. to be used as $actual in tests) would also be great. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)
s like `text/html;charset=UTF-8`." This kind of thing is achievable in userland, so the "no userland functonality" objection would appear to apply; however, it is comparatively trivial, so might get around that object on those grounds. - There was a general sentiment that rewriting/rethinking the superglobals and global response functionality would be worthwhile, but also that it is a huge undertaking, and would require several years to put in place responsibly. * * * -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [VOTE] Server-Side Request and Response Objects (v2)
> On Mar 20, 2020, at 08:31, Paul M. Jones wrote: > > Hi all, > > I have opened the vote on Server-Side Request and Response Objects at > <https://wiki.php.net/rfc/request_response>. > > The voting period will close two weeks from today on Fri 03 Apr 2020. The vote is now closed; at 11 in favor to 35 against, the RFC is not accepted. I will try to put together an after-action/lessons-learned message next week. Thanks to all who participated. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Change default PDO error mode
Hi there, > On Mar 28, 2020, at 14:02, AllenJB wrote: > > I believe it also brings the behavior inline with what developers would > actually expect the default to be in modern PHP. As do I. Every PDO wrapper I've ever written, one of the first things it does is set exceptions as the error mode. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Constructor Property Promotion
> On Mar 26, 2020, at 08:30, Nikita Popov wrote: > > Hi internals, > > I would like to submit the following RFC for your consideration: > https://wiki.php.net/rfc/constructor_promotion Big fan. Thanks for this. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] Server-Side Request and Response Objects (v2)
Hi all, I have opened the vote on Server-Side Request and Response Objects at <https://wiki.php.net/rfc/request_response>. The voting period will close two weeks from today on Fri 03 Apr 2020. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, With the name change from `ServerRequest` to `SapiRequest` (et al.), discussion appears to have waned again. I believe all relevant questions have been answered and recorded at this point. Please review the updated RFC and implementation, and present any more questions/comments/concerns you may have. Unless there are objections (or new substantive discussion) I plan to open voting tomorrow or Friday. Thanks to everyone who has participated so far! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Mike & Rowan & all, > On Mar 16, 2020, at 13:35, Mike Schinkel wrote: > >> Does anyone besides Rowan long for a different property name here? What are >> your suggestions, if any? > > I don't think this is important anymore if we call it Sapi or CGI. It was > only an issue IMO if if we were still wanting to call it Request. > > But again, just my opinion. Noted, and agreed. After checking with John Boehr, and having put together a 2.x branch using the `Sapi` prefix, I think it looks pretty good. Unless there are objections, we'll keep the new prefix, and I'll update the RFC accordingly. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Capturing reasons for votes for historical sake?
> On Mar 16, 2020, at 13:29, Mike Schinkel wrote: > > Hi all, > > It is a real shame that the PHP voting process has no way to capture a > concise description of why people voted against an RFC. ... > Would it be possible to add a feature when voting were people either need to > type in a one to two sentence reason why they voted "no" on a proposal OR > select from the reasons that others have already given when voting down the > specific RFC? I would be against making it a *requirement* but I sure would be happy to see it as an *option*. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, > On Mar 14, 2020, at 10:18, Rowan Tommins wrote: > >> On 13/03/2020 20:36, Larry Garfield wrote: >> >>> * The RFC by design is trying to take the super-globals and make them OOPy; >>> no more, no less. >>> * The super-globals are not based on HTTP. They're based on CGI, which is >>> sort of but not quite an HTTP request. >>> * So... call it CgiRequest/CGIRequest? (I am also ignoring >>> capitalization.) Because that's what it is: It's CGI request data wrapped >>> up into an object, no more, no less. > > This makes a lot of sense to me. I too find this appealing. That prefix would net these class names: - CgiRequest - CgiResponse - CgiResponseSender The only confusion I think might arise is a consumer saying, "I'm not using CGI, I'm using (fcgi|apache|etc)". Turning it over in my mind, I wonder if maybe a `Sapi` prefix would be a better alternative along this path, especially since these objects relate to the "interface between web server and PHP." <https://www.php.net/manual/en/function.php-sapi-name.php> A `Sapi` prefix would net us: - SapiRequest - SapiResponse - SapiResponseSender The only obvious objection is that the SAPI list includes 'cli'. While it not strictly outside the realm of the RFC, it certainly is not the focus; but then, tests running at the command line will be under the 'cli' SAPI, so there's at least some sort of rationalization for it. Overall, I think `Sapi` looks better than `Cgi`, and certainly better than `Server` or the other names we've considered. Any further thoughts on naming? > I also just realised that it would make sense to rename $_SERVER in the > object, the same way $_GET has become "query" and $_POST has become "input". > Maybe $request->cgi or something? I sympathize with the desire to rename (or even restructure) the apparent catchall of `$_SERVER`. But I am still reluctant to do so, especially as no other researched projects use a different name here (whereas some have replaced `$_GET` with `$query`, etc). Does anyone besides Rowan long for a different property name here? What are your suggestions, if any? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all,
That escalated quickly. :-) I'm going to reply to the only request for
clarification I could identify in this exchange -- if I missed others, please
let me know.
>> Is the proposal really suggesting that a developer would still need to do
>> `if(!empty($request->server[‘HTTPS’]) && $request->server[‘HTTPS’] !==
>> ‘off’) {…}` rather than just providing a `secureTransport` property (or
>> `https` if you prefer)?
>
> Not sure. Paul needs to answer that.
This is another one of those places where several of the individual projects
have something similar, but not close-enough to each other to represent it in
the ServerRequest object. Some honor '1' as 'on', some do not, etc.
So, yes, I'm saying that existing code using $_SERVER could use this as a
replacement:
$secure = ($request->server['HTTPS'] ?? null) === 'on';
I'm open to discussion about additions to the object for this or other
purposes, though, if we can decide on "the right way" to calculate new proposed
values.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Stephen,
Good stuff. You have stepped through my & John's earlier thought-process in
much the same way that led to the current naming.
> On Mar 13, 2020, at 09:23, Stephen Reay wrote:
>
>> On 13 Mar 2020, at 20:39, Paul M. Jones wrote:
>>
>> Do you have alternative suggestions or preferences on the names? Or, do you
>> feel that "Request" and "Response" and "ResponseSender" (without any
>> prefixes at all) would be sufficiently obvious?
>
> Hi Paul,
>
> TLDR: if you aren’t concerned about the concept of php-initiated outgoing
> HTTP requests, I think `HTTP{Request,Response,Buffer}` is quite clear in
> terms of naming. If you wanted to be more explicit about their purpose
> (and/or prevent possible confusion with either user land or potential future
> extensions handling outgoing requests), `IncomingHTTPRequest` and
> `OutgoingHTTPResponse` are very explicit, if a bit verbose.
>
> I think I did see that message, but I must admit I haven’t followed all the
> responses in the discussion.
>
> Personally I think `HTTP` makes a pretty obvious prefix (I’m not gonna get
> into a capitalisation debate), because these things are explicitly related to
> HTTP request and response messages.
I follow your reasoning. The main problem I see with "HTTP" (I won't argue
capitalization either) is that I can guarantee you there will be a very vocal
subset of users who will complain loudly and continuously that the objects do
not model HTTP messages. I would prefer to pre-empt that, especially since it
is true. ;-)
One other alternative John & I contemplated was
`Web{Request,Response,ResponseSender}` -- do you think that might be a
reasonable alternative to HTTP, one that is "adjacent" but not overly-specific?
That would net us:
- WebRequest
- WebResponse
- WebResponseSender
I didn't like the look of it previously, and I don't think I like the look of
it now, but ... (/me shrugs).
> However, that also may be confusing if people expect it to be a construct for
> making outgoing requests.
Yes, that's another tricky bit in the naming -- making a distinction between
the objects as representative of client operations (send request, receive
response) and server operations (receive request, send response). Thus the
current `Server` prefix (however unsatisfactory it may be) to indicate their
operational context.
Your `Incoming` and `Outgoing` prefixes, minus the HTTP, would net us:
- IncomingRequest
- OutgoingResponse
- OutgoingResponseSender
I will need to ponder on those.
> The user land implementation I’ve been using ’solves’ this by using a `HTTP`
> namespace, and then provides `Request` and `Response` (for an outgoing - i.e.
> curl - HTTP Request, and the corresponding HTTP Response) objects and then
> `CurrentRequest` and `CurrentResponse` for what your RFC proposes (i.e. the
> active request made to php).
Yes, userland does operate that way. However, I think adding an HTTP namespace
to PHP itself is something to be avoided, so emulating userland here is not an
option.
> As with anything any of us has written, I’m not 100% sold on
> ‘Current{Request,Response}` even after writing it, but I think it’s at least
> a little more specific about what they do, when the namespace is taken into
> account.
`Current{...}` is not something we had previously considered; that would net
us, in the global namespace:
- CurrentRequest
- CurrentResponse
- CurrentResponseSender
I will need to ponder on those as well.
Any further thoughts or opinions on this, Stephen? Or from anyone else?
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Stephen,
> On Mar 13, 2020, at 02:41, Stephen Reay wrote:
>
> I realise this is just bike shedding - the naming seems quite odd to me.
>
> This extension and the classes it provides are inherently about HTTP requests
> made to a php ‘server’, and the response it sends back - and yet it’s called
> Server{Request,Response,Buffer} etc…. The “server” part is superfluous in the
> context of a php web application, because it’s all “server” side, and while
> uncommon it’s not impossible to write *other* types of network server using
> PHP.
I share your feeling here, and I don't think it's bike shedding. The naming is
still an open question on the RFC.
I mentioned some other candidate names here ...
https://externals.io/message/108436#108702
... and re-reading your comment above, it looks like you saw that one.
Do you have alternative suggestions or preferences on the names? Or, do you
feel that "Request" and "Response" and "ResponseSender" (without any prefixes
at all) would be sufficiently obvious?
Let me know, and thanks for bringing it up!
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, > On Mar 11, 2020, at 11:36, Paul M. Jones wrote: > > Conversation on this RFC seems to have diminished. As far as I know, I have > answered all criticisms/concerns/complaints one way or another. FWIW, I have updated the Q&A points based on new discussion over the past day or so. The updated points are: Q: The proposal compares and contrasts with HttpFoundation and the various PSR-7 implementations; how does it compare to other projects? A: See this message for a starting point: https://externals.io/message/108436#108889. In short, the proposed functionality is representative of functionality common to the dozen-plus researched projects. Q: Are these global single-instance objects? A: No, you can create as many instances as you like, in whatever scopes you like. Q: Do these objects replace the superglobals? A: No. Q: Do these objects deal with $_SESSION and the session functions? A: No; it is explicitly out of scope for this RFC. Q: Readonly properties are unusual for PHP. A: Granted, though not unheard of. PdoStatement::$queryString is one precedent here. Further, of the researched userland projects, more than half of them present the relevant superglobals as nominally readonly in the public scope, making readonly access a reasonable choice here. Q: Why is ServerRequest readonly, and ServerResponse mutable? A: It makes sense that you would not want to change what you have received as a request; however, as you are in charge of creating the response, modifying it as needed seems reasonable. Further, the “readonly request with mutable response” matches half or more of the researched userland projects. Q: What would a migration path look like? A: Something like the one outlined in the later portion of this message: https://externals.io/message/108436#108893 -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Arvids, > On Mar 11, 2020, at 16:22, Arvids Godjuks wrote: > > I took a deeper look into the GitHub repo and it answered a few questions - > RFC just didn't give any examples of usage/instantiation and how you can > make a new object. I was thinking it was a read-only global type object > that lives and dies with the start and end of the request. That's my failure, then; I will add a couple of examples like that to the RFC before calling the vote. Thanks for taking the time to examine the repo, and let me know if you think of anything else. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, Conversation on this RFC seems to have diminished. As far as I know, I have answered all criticisms/concerns/complaints one way or another. So if there are no more questions, and there is no objection, I will plan to call the vote on this proposal some time tomorrow or Friday. Thanks to everyone who has participated! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Attributes v2
Hi Benjamin, From the examples, am I to understand that the RFC introduces a top-level namespace `\Php` ? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Arvids, > On Mar 5, 2020, at 05:19, Arvids Godjuks wrote: > > one question I do have here is about how PHP-PM process manager will be > able to interact with this layer? > Cause right now it does rewrite the $_SERVER variable for each incoming > request for its child processes that handle the requests > https://github.com/php-pm/php-pm/blob/a2872e13c3901401d5c2386a8ed62502db23d5f2/src/ProcessSlave.php#L463 > > It kind'a makes this not possible if there is no way to re-init the object. > While read-only is, obviously, a good idea, there are some caveats like > this that not only limit the possibilities but also what will the > ServerRequest object even look like when $_SERVER is being rewritten like > this? > > ... > > it seems that this RFC does not allow such usage at all and long-running > processing has not been taken into account at all? I have never used PHP-PM, so I am talking outside my competence here. Even so, I see the ProcessSlave::prepareEnvironment() method rewrites $_SERVER. Instead of re-initializing an existing object, would it be sufficient to create a new ServerRequest object after that point, with the newly-modified $GLOBALS values (in which $_SERVER is represented)? You would then use that new instance in the new child process. Regarding a long-running process, I could see where the entry point might create a new instance of ServerRequest as needed, using the current $GLOBALS state, and pass that new instance into whatever handler gets invoked. I am probably missing your point; if so, my apologies, and please guide me. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
-OMEfkgna7-b2IsuoWN8x_TazxEYn-yVDF2XQIqnzmHqdDO3KEKx/pubhtml Here are some notes about it: https://externals.io/message/108436#108889 As far as other languages, I did the barest bit of a survey, but since the goal of this RFC is very directly tied to PHP itself, researching other frameworks in other languages was not especially fruitful. > Thinking about porting existing codebases across, ServerRequest holding > copies rather than references would make it hard to interop with existing > code using the superglobals. /me nods along Maybe? Certainly that's true if the existing code depends on superglobal mutability at some point past bootstrapping the application. But speaking from personal experience only, that kind of mutability dependence seems relatively rare. That is, I myself do not recall seeing applications that co-opt $_GET, $_POST, $_COOKIE, etc. to continuously modify them throughout the application. *Sometimes* I see that in $_ENV and $_SERVER, but even then it is a limited sort of thing that's easily extracted to an application-specific object. However, if an application *does* depend on that kind of thing, you're right: ServerRequest would be disconnected from the superglobals, meaning that application would not be a candidate for migration to ext/request. Do note, though, that more than half of the researched projects are nominally readonly in public scope, much like ServerRequest. As such, I am encouraged to think that the interop problem you describe is not often encountered. > I've had this rewriting legacy apps that use > $_SESSION and the new framework uses an OO session handler; it's not fun > but with references can usually be made to work. In this case, what would > the migration path look like? Johannes Schlüter commented on this on 24 Feb > but I didn't understand his comment (link: > https://externals.io/message/108436#108737). $_SESSION and the session-related functions are a whole different beast, one that this RFC intentionally avoids. Much as I like ext/session, it combines too many different concerns. As you say, you cannot simply make a copy of $_SESSION and have everything else keep working; it and the session-related functions are intimately intertwined. But leaving aside $_SESSION, I opine that the migration path in a system that already treats the non-session superglobals in a read-only fashion might be tedious but not difficult. For example: 1. In your setup code, after you have made any changes to the superglobals that your application requires, instantiate ServerRequest via whatever object-sharing system you have in place (whether by DI container or by any other approach). 2. In one script (or function, or class) inject or otherwise acquire the ServerRequest instance; then, line by line, replace `$_GET` with `$request->query`, etc. Repeat for the other superglobals in that script/function/class. It is *almost* at the level of automated search-and-replace. (And along the way, you might do things like replacing `isset($_GET['foo']) ? $_GET['foo'] : 'default')` with `$request->query['foo'] ?? 'default'`.) 3. Run your regression testing (or smoke-test or spot-check) and correct any errors. 4. Commit, push, and notify QA. 5. Repeat 2 & 3 using the next script/function/class. The benefit of this approach, at least if you are treating the superglobals as read-only, is that `$_GET` continues to work alongside `$request->query`, so you need not change the entire application at once. Baby steps and iterative improvement are possible, even preferred. To be clear, I have not tried this approach on any applications myself. But, it is similar to the methodology used throughout my book on modernizing legacy PHP applications, and I imagine it would be pretty close to what would actually be needed for a migration. > In summary, I like the idea of steering people away from superglobals, > appreciate the work you've put in Thanks for saying ... > and am not persuaded by the approach. ... and noted. After reading this, what modifications to the proposal *might* persuade you (if any) short of rewriting how PHP does superglobals in the first place? Regardless, my thanks for your time and effort writing a good critique. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan, > On Mar 4, 2020, at 17:13, Rowan Tommins wrote: > >> On 04/03/2020 20:01, Paul M. Jones wrote: >> >> This RFC, in contrast, does not attempt to model HTTP messages. It does not >> attempt to discard previous ways of working. Instead, it proposes a more >> object-oriented representation of functionality that already exists in PHP, >> honoring that previously-existing approach. There is quite a bit of >> real-world experience as to how well it will work, since it takes into >> account many commonalities between existing userland projects. Thus, what >> the RFC purports to get close to is that existing way-of-working, and I >> think it succeeds about as well as can be possible for its goals. > > This is something you have said a few times, and is definitely a worthy goal, > but it's not something that comes across very strongly in the RFC itself. > There is a comparison to Symfony HttpFoundation, but it mentions as many > differences as similarities; and there is a list of 13 other implementations, > but no information on how this proposal compares to them. > > I suspect that's just because you didn't want to burden the RFC with too many > details, but if you have any notes about what functionality is common in > existing libraries, perhaps that could be posted somewhere as a kind of > appendix to show where the current design came from? Your suspicion is correct; I thought the RFC was pretty long as it was. And your suggestion is a good one; here is a Google Sheets doc of summary findings (copied from my local spreadsheets): https://docs.google.com/spreadsheets/d/e/2PACX-1vQzJP00bOAMYGSVQ8QIIJkXVdAg-OMEfkgna7-b2IsuoWN8x_TazxEYn-yVDF2XQIqnzmHqdDO3KEKx/pubhtml When you see $foo, it means the feature is presented as a property, or as a method on a public property object. When you see foo(), it means the feature is presented as a public method on the object itself. Other notes: 1. On the Request and Response objects, I have a line for "nominal public mode": - A nominal "readonly" is for the superglobal-derived public properties. The object might include one or two mutable properties, but those properties are application-specific, not superglobal-derived. Gurther, the superglobal-derived properties might be mutable within a protected scope but not a public one. - A nominal "mutable" means the superglobal-derived values are mutable from public scope. - A nominal "immutable" means the object is intended to be immutable (whether it succeeds or not). - Of the 14 projects, 8 have nominally readonly Request objects, and all but one Response object are mutable. 2. Several projects retain "Forwarded" information internally on the Request objects, but almost none of them expose it publicly. As it appears to be an commonly-calculated set of values, I did include it in ServerRequest, and made it available for public reading, so that extenders/decorators can use it. 3. Likewise, several projects expose a "client IP" or "remote address" value, but don't calculate it the same way. So even though it's a common need, and I'd like to have it in ServerRequest, there's not broad agreement on what that value ought to be. 4. Finally, several projects have some kind of Response cache methods, usually in the form of setCache() etc., and then often with individual cache directive methods. I recall that they differed in how they retained the caching information; some wrote to headers directly, others retained the directives individually and "compiled" them into a caching header at sending time, etc. So while I would like to incorporate the caching stuff into ServerResponse, I don't think there's enough commonality between the implementations to warrant that. I hope the rest of it is self-explanatory, or easily-understood; if not, let me know, and I'll answer your questions. And of course, if you notice discrepancies or inaccuracies, tell me so I can correct them. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Dan, Thanks for taking the time to bring up your concerns. While I don't expect to change your mind (nice though that would be!) perhaps other readers here will find my counter-positions useful. > On Mar 3, 2020, at 16:58, Dan Ackroyd wrote: > > Paul M. Jones wrote: > >> Are there any members here who currently expect to vote "no", > > The only reason for doing this as C code appears to be make it have > read-only properties. Not the *only* reason, though it's true that it would be difficult-to-impossible to do outside of C. As Rowan mentioned earlier, and as I opined in an unpublished version of the RFC, one other reason would be to provide a language-level OO-ish representation of PHP functions, similar to what ext/mysqli and ext/date do. > This is a hack I dispute the word "hack" -- a readonly feature is requested here from time to time -- though I do understand that it is an uncommon approach. > that would confuse a lot of developers I think you're right that it might confuse some developers, but I also opine that just as many or more would "get it" either right away or very quickly. > and instantly be added to most lists of "how PHP is bad". Adding one point to the many thousands that already exist on such ill-considered lists, so not much of a change there. ;-) > Tying this into core means that: > > - BC breaking changes could only happen on major versions. > > - Discussion of those changes would take up a lot of time, or more > likely never happen. See all of our core extensions that are > desperately in need of a maintainer to work on them. > > - It might be impossible (or at least annoyingly difficult) to write > code that was compatible with two versions of PHP, if they used this > > ... > > For stuff to be added to core, to overcome the burden of supporting in > the future, there needs to be a strong reason to add it. Not just > something that could be done. All of your points are completely true. In fact, they are true for every RFC presented on this list; past, present, and future. So while you're correct, I have a hard time seeing it as a criticism specific to this proposal. (I'd be happy to see refinement of your points toward more specificity, if feel so inclined.) Having said that, I'll present a past example that may tie it more specifically to this RFC. The Same Site Cookie proposal <https://wiki.php.net/rfc/same-site-cookie> hits around the points you mention: a change to long-standing behavior that might have entailed a BC break, discussion of that change, and code compatibility. All of those were managed quite successfully and in a reasonable timeframe. And although you voted against that proposal, it did pass, and has turned out to be pretty good; I imagine the same kind of change-success, if it is ever needed after adoption, is just as likely for this RFC as well. > As you were involved and so know, a huge amount of energy was spent > designing PSR-7, and still it was definitely not a perfect design. The > chances of the design of this API being even as close as PSR-7 was, > seems minimal. I know you're not especially a fan of PSR-7 <http://basereality.com/blog/17/PSR7_and_airing_of_grievances> so arguing in its defense, against interest, is laudable. Good form! But your phrasing about this RFC "being even as close as PSR-7 was" raises the question: "as close" to what? The PSR-7 interfaces, and their many differing implementations, attempt to model HTTP messages as immutable objects. Indeed, the PSR-7 design process ended up discounting and discarding all pre-existing ways-of-working in PHP land, to the point of ignoring all previous implementations in the FIG member projects and elsewhere. Instead, PSR-7 declared "year zero" and presented an entirely new way of working that was completely different from and unrelated to anything else in PHP-land at that time. (For a brief history of the PSR-7 design evolution, see the first few slides of my talk on PSR-7 and ADR at <http://paul-m-jones.com/talks/psr7adr.pdf>.) Among other things, that meant there was no applicable real-world experience as to how well PSR-7 would work in the mid-to-long term. That historical context may make it easier to see why "a huge amount of energy was spent designing PSR-7", while resulting in something that was "definitely not a perfect design", in order to get close to a model of HTTP messages. This RFC, in contrast, does not attempt to model HTTP messages. It does not attempt to discard previous ways of working. Instead, it proposes a more object-oriented representation of functionality that already exists in PHP, honoring that previously-existing approach. There is quite a bit of real-world e
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi everyone, All outstanding issues on this RFC appear to be resolved one way or another. With that in mind: Are there any members here who currently expect to vote "no", who have not yet chimed in? I'd like to hear your criticisms and objections, so I can at least attempt to resolve your concerns. I am especially interested to hear about technical or developer-experience shortcomings, but of course variations on "this is better left to userland" are understandable. Again, and as always, my thanks for your time and attention. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan, > On Feb 27, 2020, at 11:27, Rowan Tommins wrote: > > On Thu, 27 Feb 2020 at 17:06, Paul M. Jones wrote: > >> We spoke of this before; quoting myself from >> <https://externals.io/message/108436#108650> ... >> >>> I don't *expect* anything from existing published library authors; however >>> ... >>> >>> • I *suspect* that some will choose to ignore this extension, >>> >>> • that others will decorate or extend it, >>> >>> • and that still others may find their own work so close to ths extension >>> that they migrate over to it entirely. >> >> I continue to hold that position. > > Perhaps I am over-interpreting them, but the words you choose always seem to > me very passive, as though shrugging and saying "it might happen, or it might > not". It could be that you are over-interpreting; in point of fact, some combination of those three things is guaranteed to happen, no "might" about it. In any case, we seem to have drifted from evaluation of the proposal (per se) to other topics. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan, > On Feb 27, 2020, at 10:57, Rowan Tommins wrote: > > you seem to be happy to just put it out there and see Perhaps it was not your intent, but even so: please don't put words in my mouth. We spoke of this before; quoting myself from <https://externals.io/message/108436#108650> ... > I don't *expect* anything from existing published library authors; however ... > > • I *suspect* that some will choose to ignore this extension, > > • that others will decorate or extend it, > > • and that still others may find their own work so close to this extension > that they migrate over to it entirely. I continue to hold that position. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan,
> Why not hope that ReactPHP and others will want to use this object,
> precisely because it avoids them having to roll their own implementations
> of things?
Like I said earlier: if React ends up wanting to use ext/request, with its
tradeoffs, of course I would think that's great. But if they want to keep using
what they have already, with its own tradeoffs, that's great too.
> If somebody really wanted to use the parser without the rest of the object,
> they could trivially wrap it in a function:
>
> function parse_multipart_form_data($content) {
>$request = new ServerRequest([], $content);
>return [ 'input' => $request->input, 'uploads' => $request->uploads ];
> }
This is very similar to what I'm saying: to use your phrasing, I opine it is
better to "trivially wrap" the existing PHP functionality as part of a separate
RFC, rather than try to embed it in ServerRequest (exposed or otherwise).
To reiterate what I've said before: this RFC is a relatively conservative one.
The vision around it is to stay pretty close to PHP as-it-is, and to
incorporate those things from the researched implementations that show up over
and over again.
I know that does not lead quickly toward (what I surmise is) your vision of
overhauling how PHP presents global state, but an overhaul of that kind is just
not what this RFC aims to do.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> On Feb 26, 2020, at 14:12, Rowan Tommins wrote: > > On 26/02/2020 19:57, Paul M. Jones wrote: > >> Do you mean something like this in the ServerRequest constructor? >> >> ... > > That's the easy part, yes; the harder part is this: > > ... Yes, that would definitely be the harder part. > Recreating that functionality in userland is non-trivial, but is essential > for several use cases, e.g. an event-based server like ReactPHP, or a test > using a saved request body as a fixture. > > If both content types (application/x-www-form-urlencoded and > multipart/form-data) were handled, it would also mean that the relationship > $content -> $input would match the relationship php://input -> $_POST by > default, which seems consistent with the aim of matching existing behaviour. Yes, it would indeed. However, it strikes me that the thing to do here is not to try and embed that behavior in ServerRequest; rather, it would be to expose the existing functionality on its own, so that ReactPHP (and many others!) can use them, instead of having to roll their own in userland (a la <https://github.com/reactphp/http/blob/master/src/Io/MultipartParser.php>). -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan,
> On Feb 26, 2020, at 12:55, Rowan Tommins wrote:
>
> That's a reasonable justification. Just to check, are there other
> implementations that have both of these names side by side, or do most
> implementations have one or the other, but using this naming?
My recollection is that they have one or the other, but none with both
side-by-side. (A very few have neither.)
> The main confusion I can see is having to remember which two of these is an
> error without having to read the docs each time:
>
> isset( $request->files['attachment']['name'][0] );
> isset( $request->files['attachment'][0]['name'] );
> isset( $request->uploads['attachment']['name'][0] );
> isset( $request->uploads['attachment'][0]['name'] );
/me nods
While I too have imagined that, my impression has been that consumers of 1.x
use $files unless & until they change their systems to use $uploads, at which
point they switch over entirely to $uploads. Given that, my concerns (such as
they may have been) are soothed.
> If getUploads was a method, it could take a similar behaviour switch -
> GROUP_BY_ITEM vs GROUP_BY_ATTRIBUTE or similar. For a property, that would
> have to be part of the name, like $uploadsByItem and $uploadsByAttribute,
> which are a bit ugly.
>
> Alternatively, you could lean more heavily on the legacy aspect, and have
> $uploads and $uploadsLegacyFormat or something like that.
Noted.
Are there any others here who feel that the names $files and $uploads are "too
confusing" (for whatever values of "confusing" you find appropriate) ?
> Again, any mention of JSON or XML is drifting away from what I'm asking
> for.
Ah, my bad then.
> What I'm asking for (or rather, suggesting would be a useful and
> consistent addition) is a way to do *exactly what PHP does right now*, but
> based on a given input string, rather than the initial request.
I'm sorry, I'm still having trouble seeing what you're getting at. Do you mean
something like this in the ServerRequest constructor?
public function __construct(array $globals, ?string $content = null)
{
if (
($globals['_POST'] ?? null) === null
&&
strtolower($globals['_SERVER']['CONTENT_TYPE']) ===
'application/x-www-form-urlencoded'
) {
if ($content === null) {
$content = file_get_contents('php://input');
}
$globals['_POST'] = [];
parse_str($content, $globals['_POST']);
}
// ...
}
If so, it seems unnecessary for the goals of this RFC, even overkill.
If not, then I await correction.
> To play devil's advocate, does the [$content] property belong in the object
> at all? If it doesn't interact with any of the other properties (e.g.
> populating $post and $uploads based on form data), could "better syntax for
> getting raw request for global state" be a separate feature. Then again,
> maybe the ability to over-ride it in the constructor is enough to make it
> useful.
I continue to think it does belong there. Often enough, API developers will
read php://input to decode JSON or XML they find there, so having it
easily-available as $request->content is appealing. To boot, the other
content-related headers are present, so might as well have the content itself
there too. And as you note, it's easy enough to pass in custom $content via the
constructor, e.g. for testing.
* * *
I feel that if these are the discussion points, then we are close to exhausting
the topic (even if we do not agree on everything). Thank you for your diligence
and attention to detail!
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
t's read-only is a > separate attribute. We're really just talking about ways to construct that > self-contained state, and "everything from global state" or "nothing from > global state" seem like more natural options than "one thing from global > state, everything else not". I agree that the default $content value is an exception to everything else in ServerRequest. While it stays read-only, it does get read from php://input each time you refer to it. The alternative is to read from php://input once at construction time (when the construct $content argument is null) and retain that value in $content from the start. But in that case, when you have very large content bodies (as when there are PUT file uploads or other large payloads), then ServerRequest takes up a lot of memory, when it might not ever be used directly. Yes, "it might never be used" could be true of every element on ServerRequest, but the maximum memory use for those other elements tends to be rather smaller. In the end, letting $content read from php://input on the fly is a reasonable tradeoff; an exception that tests the rule, if you will. Over to you! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Johannes,
Thanks for continuing to evaluate the proposal.
Am I correct in thinking that your primary objection to ServerRequest is that
it is read-only? If so, do you have other objections beyond that? And if not,
please correct me.
Meanwhile, to respond to your comments ...
* * *
> On Feb 24, 2020, at 07:57, Johannes Schlüter wrote:
>
> Is there a way to integrate filter, so we can reduce (over the long
> term) the interfaces and get to a single one (getting rid of
> register_globals took almost to the day 10 years from creating super
> globals, via deprecation and changed default to removal, so I'm not
> asking for the unity tomorrow but having a plan ...)
My position is that integrating the filter extension is out-of-scope for this
RFC. To sum up prior conversation:
- Anyone using ext/filter can still do so, just via filter_var() on a
ServerRequest property, instead of via filter_input() on the superglobals
directly <https://externals.io/message/108436#108507>
- "I think you [Mike] are over-estimating how central the filter API is to most
people's workflow with requests. I think that's partly because designing
a good validation API is hard, but also because filter_input in particular is a
combination of three different concerns."
<https://externals.io/message/108436#108627>
- "[T]rying to build a single set of classes which include a system for getting
global state AND a system for parsing it in different ways AND an in-built
validation API seems like a mammoth task. And if you keep it monolithic, any
feature you miss or make a mistake on is much harder to fix later."
<https://externals.io/message/108436#108635>
> (Or we could say filter failed completely and we don'T integrate it and
> just remove it :-p no idea ...)
I have no opinion on whether ext/filter has "failed" or not. While I don't see
it everywhere all the time, I do see it occasionally; that occasional use is in
domain-level work, using filter_var() on properties and parameters, rather than
using filter_input().
> As a side note: I love the fact that the low layer is mutable. It
> allows me to take legacy code and wrap it in a more modern framework
> and fake the old environment as a migration strategy (one has to be
> aware this produced debt and needs a plan to get rid of that, but can
> be practical for a migration rather than rewrite, also useful for
> testing bad code to allow cleanup)
I'm a fan as well; I don't imagine that I would want the superglobals
themselves to be made read-only.
However, I *do* think that once they pass a certain boundary, they should no
longer be mutable. In general, I think that boundary is at the router or other
front controller system.
The ServerRequest object exists for working at or beyond that boundary; i.e.,
once you have gotten the superglobals into the state you want, copy them them
into a ServerRequest object and pass *that* object around, instead of reading
from and writing to the superglobals themselves.
>>> Let PHP provide the access to the data and promote the API library
>>> of the year.
>>
>> "API library of the year" -- heh.
>>
>> To be fair, though, the API presented by ServerRequest and
>> ServerResponse is highly similar to that presented by PHP itself; far
>> from being "API of the year" it honors existing PHP functionality
>> quite closely.
>
> So it's only "closely" to what users want?
That's not quite what I said. ;-)
To reiterate, what it "closely" does is "honor existing PHP functionality." For
example:
- instead of reading from `$_SERVER`, read from `$request->server`
- instead of calling `header("Foo: bar")`, call `$response->setHeader("Foo",
"bar")`
- instead of calling `setcookie("baz", "dib")`, call
`$response->setCookie("baz", "dib")`
That is, it's not a big jump from using the superglobals and functions, to
using the object properties and methods. Making the two ways of working very
close to each other is a goal of the RFC.
> So users will still need to wrap it?
I wouldn't think they "need" to wrap it, unless they want it to do something it
does not already do. I suspect that some will find it satisfactory as-is, and
that others will want to add custom functionality.
> So purpose is not to make it simpler to use or anything but only to disallow
> abuses like I mentioned above?
The purpose is as stated in the RFC: that is, to provide a more
"object-oriented approach around request and response functionality already
existing in PHP, in order to reduce the global mutable state problems that come
with superglobals and the various response-related
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, > On Feb 12, 2020, at 12:20, Niklas Keller wrote: > >> A: It supports async exactly as much as PHP itself does. > > Not really. PHP has built-in stream_select / non-blocking streams, so > supports the tools required for async out of the box. Per private conversation with Niklas, he notes some future conditions under which the API as presented might work with async (e.g. the arrival of fibers) -- but until that time, async is best left out-of-scope. I have updated the RFC to that effect. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> On Feb 20, 2020, at 18:42, Mike Schinkel wrote: > >> On Feb 20, 2020, at 10:26 AM, Paul M. Jones wrote: >> >> One of the "open questions" on this RFC is: are the class names >> ServerRequest, ServerResponse, and ServerResponseSender "good enough" for >> our purposes, or are there names that are "better" in some qualitative way? >> >> Having said that, would something like, say, RequestContext and >> ResponseBuffer (with ResponseSender) be "better" somehow? Or perhaps some >> other names? Or are readers here satisfied that the existing names are >> sufficient? > > > I would pick the latter. They are — to me — more descriptive of actually > what they are accomplishing than the former. Thanks for that. As it hasn't seemed to pique anyone else's interest, maybe I will add this as a secondary vote, conditional on the primary one passing. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, Off-list discussion with some vendors and consumers indicates that adoption and migration might be eased by the following changes to ServerResponseInterface: - Add the following methods: - `getHeader(string $label) : ?string` - `hasHeader(string $label) : bool` - `getCookie(string $name) : ?array` - `hasCookie(string $name) : bool` - Modify `add*()`, `set*()`, and `unset*()` to be fluent (allow method chaining) Since these changes fit in well with the RFC goals, and do not substantially modify prior usage expectations, John Boehr has applied them to the extension, with documentation and tests. Further, one evaluator noted that ServerResponseSender::sendContent() did not allow for iterables/generators as content; that has been remedied as well. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, One of the "open questions" on this RFC is: are the class names ServerRequest, ServerResponse, and ServerResponseSender "good enough" for our purposes, or are there names that are "better" in some qualitative way? The original thought was Request and Response, but I thought it might be too easy to think of them as client-related, rather than server-related. Then I tried PhpRequest and PhpResponse, but having "PHP" in the name seemed unnecessary, as this is PHP after all. I settled on ServerRequest and ServerResponse to point out that they are server-related. Having said that, would something like, say, RequestContext and ResponseBuffer (with ResponseSender) be "better" somehow? Or perhaps some other names? Or are readers here satisfied that the existing names are sufficient? And thanks to the many folks here who have already provided such valuable feedback! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
w ServerRequestFactory())->new();` and voila: the >> equivalent of `$_POST`, populated from JSON content, stored as >> $request->input. > > I was actually thinking of the opposite: given a request body which didn't > come from global state, but which contains data in multipart/form-data > format, extract the key-value pairs and attached files. Is that something PHP "itself" already does? If not, I have to consider it out-of-scope for this RFC. > Rather than accepting the content body as an optional constructor parameter, > what if there were two named constructors: > > - fromSuperGlobalArrays($server, $cookie, $post, $get, $files) > - fromRawRequestBody($server, $cookie, $body) If consumers/users of ext-request wish to create factories or builders to instantiate a ServerRequest instance, it is within their purview to do so. > In the first case, accessing the raw body on the object could give null, > because none is known - defaulting to global state seems like a mistake if > decoupling from global state is an explicit aim. Your point on global state is well-taken; I will try to remember in future to phrase it as "global *mutable* state." (AFAICT, php://input is not mutable, though as you correctly point out, it is global.) > if you look at pretty much any existing Request wrapper, it will make some > attempt to extract a URL from the $_SERVER array. That really feels like a > missing feature of this one right now. Yeah, my bad on not documenting it earlier -- please consider the "missing" feature "found." ;-) > I hope my comments aren't coming across as too negative. Not "negative", but as you say ... > Maybe our visions for what this should be are just too different ... I think your goals are loftier here than proposal's. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
;
> This I find less convincing. To quote from further down the e-mail, I wrote:
>
>>> ...you can do almost as much in that direction as the RFC by writing
>>> "$get=$_GET; unset($_GET);" The hard problem is that the entry point for a
>>> request is in global scope, not a main() or handleRequest() function.
>
> and you replied:
>
>> Another "hard" problem is carrying those values around in the system once
>> they are decoupled from global state; the objects in this RFC purport to do
>> so.
>
> If all the object does is "carry around" a copy of the superglobal arrays, I
> can write it in about a dozen lines of code.
I answered this above, but to reiterate: "carrying around" is *one* thing
ServerRequest does, but not *all* it does.
> Again, the response object is more powerful in this regard, because we can't
> currently pass around a list of prepared cookies and trivially output it to
> the client.
>
> Along the lines of my previous message about decoupling concerns, I would
> personally like the response parts of the proposal split out and re-cast as a
> kind of "response buffer".
I admit I considered this. However, it makes more sense to me in terms of
symmetry/complementarity, and in terms of "what we need on a daily basis", to
provide both the request object and the response object together.
>> I had considered mentioning the dual OO+procedural APIs of mysqli, date,
>> etc. but it seemed too much in an already-long RFC; I'm glad you brought it
>> up, as I did have it in mind.
>
> This is an interesting comparison to consider. Just as those extensions have
> procedural options for people who can't stand objects, the current proposal
> has objects for people who like "OO-ish".
Yes, I think so too.
>>> Introducing these objects as part of a new calling convention for PHP
>>> scripts would definitely add value, and make them a true replacement for
>>> the superglobals, but that would be a very different RFC.
>>
>> That does seem rather ambitious. If you feel that's a valuable thing to add
>> to PHP, perhaps it could be part of a future RFC, maybe even one that uses
>> the objects in this RFC as a starting point.
>
> One of the things I don't like about the current proposal is that it's
> modelled so closely around the current superglobals that I fear it would
> actually be *harder* to replace them.
Maybe? I can similarly imagine that if new-and-different superglobals appear,
the ServerRequest object can evolve to contain and/or translate between them.
> Parsing a request body from an arbitrary source into arrays that match the
> structure of $_POST and $_FILES would be a really useful feature.
Yes, although one can do at least the $_POST portion with ServerRequest as it
is now. For example, a naive userland factory might do this:
class ServerRequestFactory
{
public function new(array $globals, ?string $content = null) :
ServerRequest
{
if ($this->isJson($globals['_SERVER']['CONTENT_TYPE'] ?? '') {
$globals['_POST'] = json_decode(
$content ?? file_get_contents('php://input'),
true
);
}
return new ServerRequest($globals, $content);
}
protected function isJson(string $contentType) : bool
{
return $contentType === 'application/json'
|| substr($contentType, -5) === '+json';
}
}
Call `$request = (new ServerRequestFactory())->new();` and voila: the
equivalent of `$_POST`, populated from JSON content, stored as $request->input.
> I also really want to see the day when I never have to interact with $_SERVER
> again. Other than renaming it, this object's design makes that less likely,
> not more.
>
> Imagine if in future we're able to redesign the internals so that there is a
> dedicated and reliable field for the requested URL; the current object
> doesn't have anywhere we can put that. If we add it later, it will be too
> late, code will be written that passes around ServerRequest objects, but
> relies on the full array of CGI variables to reconstruct the URL.
>
> If this object took a more opinionated view of what behaviour to encapsulate,
> we could simply hide the "server" array completely. Common use cases would be
> exposed via methods, and rarer use cases would have to be added in userland
> with their own copy of $_SERVER. Then my dream of deprecating $_SERVER could
> mean something other than moving it into an object.
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, Per the past several days of discussion, John Boehr and I have modified the proposal: - ServerRequest - The `$env` property mapping to `$_ENV` has been removed - The `$requestedWith` property mapping to `$_SERVER['HTTP_X_REQUESTED_WITH']` has been removed - The superglobal `$_GET` now maps to the property `$query` (instead of `$get`) - The superglobal `$_POST` now maps to the property `$input` (instead of `$post`) - A new interface, ServerResponseInterface, is now available; ServerResponse implements it There are still outstanding comments and questions yet to be resolved. Thanks to everyone who has participated thus far! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
> On Feb 18, 2020, at 08:10, Côme Chilliet > wrote: > > to me that means we also need an addContent method. I can see why we'd think that; it's symmetrical, if nothing else. Even so, none of the researched implementations have a method like that. As far as I can recall, they call have setContent() and getContent() equivalents, but no addContent() equivalent. They all work much like you point out here ... > Otherwise people will have to carry a global $content along side $response, > or use setContent(getContent().$additionalContent). ... although usually it's not a global $content. Instead, the $content is built up from a template or other subsystem of some sort, and then assigned to the response when complete. For example: $content = $template->render(); $response->setContent($content); So, I am reluctant to add something that no other implementations, across many years and many authors, have actually found a need for. Any further thoughts on this? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Côme,
> On Feb 18, 2020, at 03:24, Côme Chilliet
> wrote:
>
> Le jeudi 13 février 2020, 09:16:49 CET Paul M. Jones a écrit :
>
>> Yeah, naming is one of the hard problems. I considered $query as an
>> alternative property name for $get, but in the end, the `$_GET => $get`
>> symmetry was too great to ignore. If others here feel that $query is a
>> better name for `$_GET` than $get, I will submit to consensus on that point.
>
> query is definitely better than get.
Excellent.
> Regarding post, I’m fine with body, parsedBody and input.
>
> I get the idea of input to mimic php://input, but if I understand things
> correctly, php://input is raw body, while $request->post is parsed body, so
> naming them alike might actually cause confusion?
Might, might not. I don't think there is any "good" name here, only names that
are less-bad than others.
> I still do not understand this.
> echo adds content to the response, it does not replace it.
> So the equivalent function should be $response->addContent.
>
> I would expect $response->setContent to replace the content.
Ah, I see what you are getting at now ...
> Can you explicit behavior for this:
>
> $response->setContent("a\n");
> $response->setContent("b\n");
> $responseSender->send($response);
>
> Compared to
>
> echo "a\n";
> echo "b\n";
... the output would be "b\n". As you say, setContent() replaces whatever
content is already in the ServerResponse. While the comparison for a single
echo is accurate, the comparison for multiple echoes would be:
$content = "a\n";
$content .= "b\n";
$response->setContent($content);
$responseSender->send($content);
Does that help to clarify?
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Rowan, I apologize in advance for the length of this email. I hate reading walls-of-text, but the answers are necessarily long. I have tried to break it up into bullets where possible for easier reading. > On Feb 15, 2020, at 19:37, Rowan Tommins wrote: > > On 15 February 2020 20:10:30 GMT+00:00, "Paul M. Jones" > wrote: > >> Hi all, >> >>> On Feb 15, 2020, at 02:01, Larry Garfield >>> wrote: >>> >>> ... is this proposal intended to supplant HttpFoundation and PSR-7 >>> ... ? >> >> This is question is answered in the RFC introduction > > You've cut Larry's question in half there, and in doing so made it seem like > a repeat, when it is not. The second half of the sentence is this: > >> ...or to become a common underpinning that both of them wrap, or to be a >> third cohabitating implementation in the ecosystem? > > I haven't seen you answer that part yet: do you expect existing userland > libraries to migrate from wrapping $_GET etc to using these built-in > wrappers. If so, what benefit does it bring those libraries? If not, who is > its intended audience? I really did think the answers to these were obvious, or easily-inferred, but obviously I was wrong. I will attempt to expand. Q: "Do you expect existing userland libraries to migrate ... ?" A: To be clear, I don't *expect* anything from existing published library authors; however ... - I *suspect* that some will choose to ignore this extension, - that others will decorate or extend it, - and that still others may find their own work so close to this extension that they migrate over to it entirely. Further ... - I suspect that developers of in-house unpublished request/response objects may find this useful for their own purposes, - and that developers who are using $_GET, header(), etc. will be pleased to find an OO-ish system that operates much like PHP itself already does, easing their transition away from global state. Finally ... - I suspect that some *consumers* of existing libraries will feel this extension is not their preferred way of working, and continue on with whatever libraries they already use, - while other consumers of those libraries will prefer this extension in their place. On reading over this, I suppose I do have an "expectation" of library authors and their consumers: that as good engineers they will evaluate this extension in reference to their own circumstances, and choose to use it (or not use it) based on the tradeoffs they find for their situation. Q: "What benefit does it bring those libraries?" A: Whatever benefits their authors happen to see in it. For myself, and as noted by Jan Schneider and others, those benefits center around having a built-in OO-ish request/response object set that does pretty much just what PHP itself already does, and that is well-suited to our daily work, without needing to incorporate comparatively large libraries into our projects for what we consider to be relatively simple purposes -- those purposes being "reading the request inputs" and "sending the response outputs". Q: "Who is its intended audience?" A: I always thought of the "intended audience" as the much the same as for any RFC: that is, developers working on a website who want PHP to provide a reasonable set of functionality for doing so, request/response objects being part of that set in a language as closely related to the web as PHP is. (As a fun side note: for all its apparent simplicity, this is an extraordinary question. Unless I have missed something, I don't recall it being asked directly of any RFC before. A Google search against wiki.php.net and externals.io reveals a double-handful of results on the terms "intended audience" and "target audience", but the only even indirect question about it on an RFC is in relation to the JIT, here: <https://externals.io/message/103903#103995> -- and it's by you. :-) * * * Rowan, you quoted Larry asking if this extension was ... >> to be a third cohabitating implementation in the ecosystem? ... that is, third after HttpFoundation and PSR-7. (By way of preamble, and to reiterate what I've said before: I would prefer to discuss this RFC on its own terms. But, as you and others want some discussion in context of other projects, I will do so. My apologies if I sound negative or critical toward those projects.) It turns out the question is kind of a funny way of describing the situation, in that PSR-7 is not an implementation of anything. (Full disclosure: I was a sponsor on the PSR-7 proposal.) PSR-7 is instead a set of interfaces; that is, they "are abstractions around HTTP messages and the elements composing them."
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, > On Feb 15, 2020, at 02:01, Larry Garfield wrote: > > ... is this proposal intended to supplant HttpFoundation and PSR-7 ... ? This is question is answered in the RFC introduction; quoting from there: The SQLite “about” page says, “Think of SQLite not as a replacement for Oracle but as a replacement for fopen().” https://www.sqlite.org/about.html Likewise, think of this RFC not as a replacement for HttpFoundation or PSR-7, or as a model of HTTP messages, but as an object-oriented alternative to superglobals, header(), setcookie(), setrawcookie(), and so on. > PDO was mentioned previously as a model. I did not mention PDO as "a model". I mentioned PDO (along with other extensions) to illustrate a counter-argument to objections based on the availability and comparability of userland implementations. The counter-argument summary was: That's not to say "because PDO was allowed into core, this RFC must therefore be allowed into core" but to say "those objections alone were not a barrier to PDO, so they alone should not be a barrier to this RFC". The argument, and my counter-argument, are here: <https://externals.io/message/108436#108493> -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi all, > On Feb 14, 2020, at 10:47, Benjamin Morel wrote: > >> >> What about $query and $body? That would be closer to the terminology >> used in HTTP RFCs. > > > The problem is that $body is typically used to get the raw message body as > a string or stream. > > I was thinking more something along the lines of $bodyParams, which is more > verbose but leaves no ambiguity: *$queryParams* and *$bodyParams*. I get the desire to disambiguate. But as an added consideration, there's a desire for consistency; when adding a -Params suffix to those names, it might then make sense to have $serverParams, $cookieParams, etc. Looking at it that way, I don't think a -Params suffix is necessary. I would think $query would be enough. As for the other name, the one for the $_POST equivalent, $body doesn't seem quite right to me; it seems a little close to $content. I've also been thinking about $values, $params, $parsedContent, $contentValues, $bodyValues, $contentArray, and other variations with and without prefixes and suffixes, but $input is the one that feels like the least-terrible alternative to $post for me, esp. given the connection to php://input. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Côme & Niklas, > On Feb 13, 2020, at 04:52, Côme Chilliet > wrote: > > Le mercredi 12 février 2020, 19:20:56 CET Niklas Keller a écrit : > >> Naming >> >> I think we shouldn't take over the naming of the super globals, e.g. >> $_GET really contains the query parameters and has nothing to do with >> GET or POST, so $request->getQueryParameter(...) would be a better >> name. > > I think this remark is really on point. > GET and POST are HTTP methods and not ways of passing data. You can have > query parameters on any request, and you can have POST data with a lot of > other HTTP methods, as is commonly used in REST APIs. Your comments on naming are well-made. While working on the implementation, we tried out $query instead of $get, on exactly the premise that you state: i.e., that `$_GET` holds the query parameters, and has nothing to do with the GET method. But in the end, we settled on mapping more directly from `$_GET` => `$get`, and `$_POST => $post`. Having said that, we are willing to revisit that naming decision if there's support for doing so. Perhaps: - rename $get to $query, populating it from `$globals['_GET']`, on the basis stated above - rename $post to $input, populating it from `$globals['_POST']`, on the basis that it typically relates to the parsed form of php://input Your (and/or anyone else's) thoughts on that? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Mike,
Thanks for your continued evaluation of the RFC.
> Take a look at WordPress. It does a lot of "fixup" to $_SERVER` variables —
> to deal with badly implemented web servers — to ensure all known variables
> have a value and that the format of the value is consistent.
>
> ...
>
> Another option actually would be to allow changes to $_SERVER prior to
> instantiating ServerRequest() the first time.
Believe it or not, this RFC does make allowance for what you're describing, as
a result of requiring a $globals array as the first parameter. An
application-specific builder or factory can modify those $globals values as
desired, before instantiating ServerRequest with the modified values.
For example:
namespace App;
use ServerRequest;
class ServerRequestFactory
{
public function new(array $globals, ?string $content = null) :
ServerRequest
{
// do fixup to $globals['_SERVER'] ...
// ... then:
return new ServerRequest($globals, $content);
}
}
$request = (new \App\ServerRequestFactory())->new($GLOBALS);
I can easily imagine many ways to achieve the same end (i.e., modification of
the constructor arguments before instantiating ServerRequest).
Do you get where I'm coming from?
>> First, I'd have to decline adding request() (or $request) at all; my opinion
>> is that one ought to be reading from $get, $post, $cookies, etc.
>> specifically, not from a pool of those values.
>
> That's definitely fair. I almost did not include request() in my suggestion
> but did because PHP has $_REQUEST.
Good enough. :-)
> Why a method is important is to support filters (I guess I assumed that was
> obvious but realize now it was not.) For example:
>
> $request->get('redirect', FILTER_SANITIZE_URL);
> $request->get('product_id', FILTER_SANITIZE_NUMBER_INT);
> $request->get('email', FILTER_SANITIZE_EMAIL);
>
> You could potentially even have scoped, easier to remember constants that can
> work with autocomplete:
>
> $request->get('redirect', ServerRequest::URL);
> $request->get('product_id', ServerRequest::INT);
> $request->get('email', ServerRequest::EMAIL);
[snip]
I do see what you mean. Even so, I think filtering is out-of-scope for this
RFC. Certainly I want to avoid adding methods to the ServerRequest class, which
as envisioned is a bag of values much the same way $_GET, $_POST, $_SERVER,
etc. are bags of values.
>>> Would you not also add an option to generate a warning when using them for
>>> those who want to deprecate their use in their own code (deprecating across
>>> the board would be too extreme give how much CMS and framework code uses
>>> them intimately.)
>>
>> That seems a bit much at this point. ;-)
>
> Really? Seems like this and some guard code is all it would take:
>
> ini_set( "disallow_superglobals", true);
Even if that's true (and I think that example masks some complexity) I must
maintain that it's out of scope for this RFC.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Ruud,
> On Feb 13, 2020, at 00:45, Ruud Boon wrote:
>
> Hi!
>
> I really like this RFC.
Glad to hear it!
> In the the RFC I see that $content will return php://input using
> file_get_contents on the fly. Can we add the possibility to get a reference
> to the stream as well?
By "get a reference" I presume you mean "an open file handle" (a la `return
fopen('php://input', 'rb')`).
In which case: maybe? I can see where that would be useful for extremely large
request bodies in a memory-constrained environment.
But the question becomes: is that needed frequently-enough across a wide-enough
range of PHP developers to warrant inclusion in this RFC? I don't recall seeing
any userland implementation from my research provide such a thing. That makes
me think it's a comparatively infrequent need.
If many others disagree with that assessment, I'm happy to entertain the
possibility of adding something like it to ServerRequest.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
that object returns will be
cast to string at this point, invoking the __toString() method if present.
• Otherwise, the content is echoed as a string; note that objects will be cast
to string at this point, invoking the __toString() method if present.
There are limitations to that approach, but experience has shown that it covers
the vast majority of common requirements.
> The Request object should be mutable, e.g. you might want to change
> the client IP to be based on a x-forwarded-header instead of the TCP
> source address.
That's a great example.
First, note that ServerRequest avoids setting a $clientIp property. Further,
*extensions* to the ServerRequest object might well be mutable. So, to go with
your example, you would be well within bounds to do something like this:
class MyServerRequest extends ServerRequest
{
private $clientIp;
public function __construct(array $globals, ?string $content = null)
{
parent::__construct($globals, $content);
if ($this->forwarded) {
$this->clientIp = // ...
}
}
public function getClientIp()
{
return $this->clientIp;
}
}
You could do that for all your custom calculations on a ServerRequest object.
> Other Commentary
>
>> A: It supports async exactly as much as PHP itself does.
>
> Not really. PHP has built-in stream_select / non-blocking streams, so
> supports the tools required for async out of the box.
I will address this separately, per the resolution of our private email
conversation.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Ben, > On Feb 11, 2020, at 10:58, Ben Ramsey wrote: > > Regarding the array of arrays for $accept* and $forwarded, what are your > thoughts on using value objects with properties, rather than arrays with keys? It's a fair suggestion, but I am not keen to expand the number of new declarations any more than necessary. To play with your idea a little bit, let's say we start with ... - ServerRequest - ServerResponse - ServerResponseSender ... then to bring in Jan Schneider's suggestion, we add ServerResponseInterface (4 classes). Then we add the value objects themselves: ServerRequestAcceptValue and ServerRequestForwardValue. That's 6 classes. That's maybe not so bad. But, once we start down this path, it's easy for me to imagine what comes after. For example, since we're trying to do "the right thing," someone will suggest to typehint the properties "correctly." Instead of arrays of value objects, they probably ought to be collection objects. That gets us ServerRequestAcceptValueCollection and ServerRequestForwardValueCollection, and we're at 8 classes. Then someone is likely to say that there ought to be interfaces for all those so their implementations can get swapped out. That's ... - ServerRequest - ServerResponse - ServerResponseInterface - ServerResponseSender - ServerRequestAcceptValue - ServerRequestAcceptValueInterface - ServerRequestAcceptValueCollection - ServerRequestAcceptValueCollectionInterface - ServerRequestForwardValue - ServerRequestForwardValueInterface - ServerRequestForwardValueCollection - ServerRequestForwardValueCollectionInterface ... 12 classes and interfaces. And probably not done yet, once others really sink their teeth into it. Now, that's not a *wrong* approach -- but it does seem like overkill to me. Or, we could avoid starting down that path and stick with arrays, which in ServerRequest are read-only and immutable and get us all the things we actually need for our daily work here. Of those two, I prefer the minimalist approach of arrays for this RFC; the "effort-to-benefit" ratio is much better. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Allen & Robin, Allen, you asked: > On Feb 12, 2020, at 15:27, AllenJB wrote: > > This might be more a "future scope" thing, but I would like to see a way to > access the raw request body as part of this. Currently (as far as I know) the > only way is to open/read php://input, which isn't particularly intuitive in > my opinion. Robin asked the same thing earlier: > On Feb 11, 2020, at 08:24, Kingsquare.nl - Robin Speekenbrink > wrote: > > What i haven't clearly seen in the RFC nor the interfaces of the proposed > objects: how will this handle PUT / php:://input / raw posted data? Or am i > missing something? Answer: the php://input stream is accessible via the ServerRequest $content property; see <https://github.com/pmjones/ext-request#content-related>. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Albert, > On Feb 11, 2020, at 11:22, Albert Casademont > wrote: > >> Am 11.02.20 um 13:42 schrieb Albert Casademont: >> >>> This is very interesting, thanks! >>> >>> Would it make sense to also add an INI setting to disable superglobals >>> and response functions? >> >> no because changing basic language behavior that way is not helpful for >> code meant to run everywhere and not stop working just because tomorrow >> someone changed a random ini setting > > That could be said for all INI settings: yes they can break things if you > touch them without knowing what they do. > > I think it might make sense to be able to disable superglobals and response > functions if your codebase is committed to using the new classes, much like > the old "register_globals" did. Why pollute the global namespace if you > don't need them? I share Harald's opinion here. I think a .ini setting to disable superglobals and the response-related functions is out-of-scope for this RFC. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Jan, > I like this proposal a lot, since it provides a clear, concise interface to > these commonly uses, yet inconveniant to use, existing functions and > variables without having to always use a full-featured userland library. Glad to hear the RFC is hitting the right notes! > Speaking of interfaces: since you suggest using decoration and composition > over extension for ServerResponse, I am missing a ServerResponseInterface, so > that you can easily typehint such userland decorators. I am not opposed to a ServerResponseInterface, if John Boehr is not -- though at the same time, I am wary of expanding the number of new declarations too much. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Johannes, > What indication is there that this will be more successfull than the > filter API? Fair question. While I can't say how successful (or not) ext/filter has been, I *can* say that the proposal does not present extraordinary or dramatically different ways of working than PHP does currently. The extent of the RFC is only to provide behaviors similar to what PHP already does, in object-oriented dress. That is, whereas ext/filter might have been been described as "a new and different way of working", the concepts and functions in this RFC (even down to the method and property names!) should be immediately familiar even to junior PHP developers. > Historically PHP isn't really successful in providing higher level APIs > to things and I think leaving this to userland is very viable, since > composer and performance improvements in later PHP 5 and PHP 7. I addressed the "userland" argument in my response to Mark Randall; please forgive me for not repeating it here. > Also use of $_* is fast to grep for and gives me directly in the grep > an idea about the mess-factor of a code base, tracing all calls to a > member of an instance of a class is harder. (and yes, references etc. > to super globals aren't trivial to trace, but also rare) I feel your pain! I do a lot of legacy work too. The `$_` signature makes grepping easy, so that I can find places where there is spooky-action-at-a-distace from globally mutable state. However, ServerRequest is intended to reduce or remove that globally mutable state. The $request->get property is readonly, and neither global nor superglobal. So, while it is tougher to grep for `->get` and know that you have found a ServerRequest property, the *need* to do so should be much less even in legacy codebases. > Let PHP provide the access to the data and promote the API library of the > year. "API library of the year" -- heh. To be fair, though, the API presented by ServerRequest and ServerResponse is highly similar to that presented by PHP itself; far from being "API of the year" it honors existing PHP functionality quite closely. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Mike, > I like this, a lot. ... In general I think this would definitely be a nice > enhancement to PHP, IMO. Thanks for saying! > I do have questions about ServerResponse. It is not clear how that interacts > with existing echo, header(), setcookie(), etc? You say it creates a buffer; > is $responseSender->send($response) effectively the same as having issued > regular echo, header(), setcookie(), etc. all at once? That's correct. ServerResponse stores the (mutable) state of the response; ServerResponseSender reads from the ServerResponse and calls header(), setcookie(), etc. with its values. > each instance of $response has it's own buffer and can be sent at any time That is also correct. > Regarding ServerRequest ... How about instead creating an empty mutable > object with the constructor and then a method with an optional array > parameter that adds the values and "locks" it to be mutable, i.e. > > $request = new ServerRequest(); > $request->initialize(); > // OR > $request->initialize([ >'_SERVER' => [ >'foo' => 'bar', >], > ]); > > With this approach someone could create a class that contains the > ServerRequest and build the object up to be anything they like which could be > useful for testing, i.e. > > $request = new ServerRequest(); > $request->get = [ 'foo' => 'bar' ]; > $request->cookie = [ 'id' => 123 ]; > $request->nv = $_ENV; > $request->server = $_SERVER; > $request->lock(); That is essentially what it does now; the difference is that you mimic the $GLOBALS array at construction time, and the instance locks automatically: $request = new ServerRequest([ '_GET' => ['foo' => 'bar'], '_COOKIE' => ['id' => 123], '_SERVER' => $_SERVER, ]); // $request is now locked The class that contains ServerRequest would then build up that array for the constructor. Do you feel that's close enough to what you're asking for? > I would also suggest considering to add get(), post(), request(), cookie(), > server() and end() methods to ServerRequest First, I'd have to decline adding request() (or $request) at all; my opinion is that one ought to be reading from $get, $post, $cookies, etc. specifically, not from a pool of those values. Second, if I understand you correctly, I much prefer the property access over the method getter; it just "looks and feels better": $request->get['foo'] vs $request->get()['foo']; Let me know if that makes sense to you or not. > incorporate the functionality of filter_input(). Otherwise we have to bypass > the objects to get filtering. I don't think you'd have to bypass the objects to get filtering; unless I am missing something, this ... $foo = filter_input(INPUT_GET, 'foo', FILTER_SANITIZE_SPECIAL_CHARS); ... would easily become this: $foo = filter_var($request->get['foo'], FILTER_SANITIZE_SPECIAL_CHARS); There might be behavioral nuances between the two, but the point is that you can still do filtering. > Would you not also add an option to generate a warning when using them for > those who want to deprecate their use in their own code (deprecating across > the board would be too extreme give how much CMS and framework code uses them > intimately.) That seems a bit much at this point. ;-) I hope that answers all your questions. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Mark, > On Feb 10, 2020, at 11:02, Mark Randall wrote: > > I suspect this is a similar sentinment to the previous version, but I can > personally see no major benefit to having this as a core extension. > > I think the reality is that discussing it "on its own merits" is to > completely ignore the wider ecosystem that already performs these functions, > with more capabilities, and with potentially hundreds of thousands of > implementations already in place. > > Does it add capabilities which cannot exist in userland or cannot exist in a > reasonably performant way? Doesn't seem so except for a readonly property. > > If not, leave it to userland. I completely understand that sentiment; I recognize that it is shared by others on this list and elsewhere. But if you'll allow me, I'd like to present a counterargument in relation to previous PHP extensions. When ext/pdo was added to core, there was already a "wider ecosystem that already performs these functions, with more capabilities, and with potentially hundreds of thousands of implementations already in place." Some of those implementations at the time included (I'm working from memory here) AdoDB, Metabase, MDB, PEAR_DB, and many more that I cannot recall. PDO did not (to my knowledge) "add capabilities which cannot exist in userland or cannot exist in a reasonably performant way". (I'll grant that FETCH_INTO_OBJECT setting properties directly without using the constructor was not possible in userland, but that's an exception that tests the rule.) Indeed, PDO had a relatively reduced feature set in comparison to some of those userland libraries, especially AdoDB. And yet, PDO has turned out to be of great benefit, because it brought together features into core that (figuratively speaking) everybody needed and was rewriting in userland over and over. PDO is the strongest example here, but depending on how you count, there are 2-3 other extensions that also serve: ext/date, ext/phar, and (reaching back to antiquity) ext/session. So, there is a long history of widely-needed userland functionality being brought into core. I would say this RFC is a pretty tame example of doing so; the proposal presented here is very similar to the way PHP itself already does things, just wrapped in object properties and methods, and is very similar to how things are being done across a wide swath of userland. Now, it is possible that the objections you raise *should* have prevented PDO (et al.) from going into core. If that is the case, and (in hindsight) we think it was a mistake to allow them, then consistency alone makes your objections valid here as well. However, if (in hindsight) it was *not* a mistake to allow those extensions, then the raised objections are not especially strong arguments against this RFC. That's not to say "because PDO was allowed into core, this RFC must therefore be allowed into core" but to say "those objections alone were not a barrier to PDO, so they alone should not be a barrier to this RFC". I hope that's an understandable counterargument, even if you don't agree with it. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Michał, Good to hear from you! (While writing this, I realized I made a couple of mistakes in the RFC examples related to CONTENT_LENGTH and CONTENT_TYPE that might have caused confusion; I have now fixed them.) > On Feb 10, 2020, at 10:46, Michał Brzuchalski > wrote: > > Hi Paul, > > thanks for bringing it back. Got some questions: > > 1. In your RFC $_ENV is bound to $request. > > Looking at HttpFoundation can see it's build from $_GET, $_POST, $_FILES, > $_COOKIE, $_SESSION and then looking at PSR ServerSideRequest it's build from > $_COOKIE, $_GET, $_POST, $_FILES, $_SERVER but none of them bounds $_ENV. > > Server environment variables basically don't change over time when server > process runs. What is the specific use case that requires them to be coupled > with $request instance? I have no specific use case; I recall that $_ENV showed up in more than a couple of reviewed implementations, and so included it here. If there is no objection from John Boehr (who did the majority of heavy lifting C), or from anyone else, then I would be fine with removing the ENV-related element. I have no strong feelings on $_ENV representation either way. > 2. In your RFC all headers are mapped to $request properties > > This behaviour is unclear and unusual to me, for eg. in summary can see that > if server request has "Header-Name" it is found in > $_SERVER["HTTP_HEADER_NAME"] and that one is bound to > $request->headers["header-name"], ok but the next line with example for > "Content-Type" shows that it's bound to $request->contentType - which means > probably that it can be accessed in $request->headers["content-type"] as > well, right? seems logic. I'm not sure if that is a question/comment/criticism, or a statement of "OK so far, but ...". Please bear with me, so I can make sure I'm addressing your question properly. First: Not *all* headers are mapped to $request properties; the only ones that get special $request properties are the ones that showed up as frequently getting special treatment in other implementations. Next: the $header array is populated by all $_SERVER['HTTP_*'] values, plus $_SERVER['CONTENT_TYPE'] and $_SERVER['CONTENT_LENGTH']. The latter two do not follow the 'HTTP_*' pattern because of RFC 3875; they come in as (e.g.) `Content-Type: text/plain`, so you might expect $_SERVER['HTTP_CONTENT_TYPE'], but RFC 3875 dictates otherwise. Finally: yes, $request->header['content-type'] is available at the same time as $request->contentType, but they are not quite the same thing. The Content-Type header also allows you to specify a charset, which value gets populated into $request->contentCharset. So, you can read these values these ways: - $request->header['content-type'] => 'text/plain; charset=UTF-8' (the original header) - $request->contentType => 'text/plain' (parsed out by ServerRequest) - $request->contentCharset => 'UTF-8' (parsed out by ServerRequest) Likewise, PHP puts `Content-Length: 123' into $_SERVER['CONTENT_LENGTH']; ServerRequest additionally puts it into $request->headers['content-length'] as a string; and then further tries to represent the value as an integer in $request->contentLength. So: - $request->server['CONTENT_LENGTH'] => (string) '123' - $request->headers['content-length'] => (string) '123' - $request->contentLength => (int) 123 My apologies if all of that was stuff you already knew and understood. (And if you did not already know it, maybe that means I should write up a narrative of the logic being applied.) > Going further, for eg. $_SERVER["PHP_AUTH_PW"] is bound to $request->authPw > and then what will happen if the request will receive "Auth-Pw" header? In that example, PHP would populate two $_SERVER elements: 'PHP_AUTH_PW' from the password, and 'HTTP_AUTH_PW' from the header. ServerRequest only populates PHP_AUTH_PW into $authPw; the HTTP_AUTH_PW value would (per the above description) go into $request->headers['auth-pw']. I hope that made sense; let me know if it did not. > With those above I would see a set of getters like getContentType() or > getAuthPassword() etc. instead of ServerRequest instance properties and a > single point to retrieve header values just like well known ParameterBag's > from HttpFoundation to operate on get, post, headers etc. Does the above explanation help to modify your preferences here? If not, we can continue talking about it. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Server-Side Request and Response Objects (v2)
Hi Internals, After a couple of years of incubation, I am happy to offer a second version of this RFC: https://wiki.php.net/rfc/request_response It proposes an object-oriented approach around request and response functionality already existing in PHP, in order to reduce the global-state problems that come with superglobals and the various response-related functions. The SQLite "about" page says, "Think of SQLite not as a replacement for Oracle but as a replacement for fopen()." <https://www.sqlite.org/about.html> Likewise, think of this RFC not as a replacement for HttpFoundation or PSR-7, or as a model of HTTP messages, but as an object-oriented alternative to superglobals, header(), setcookie(), setrawcookie(), and so on. Thanks in advance for your time and consideration while evaluating it. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS Account Request: nicolasgrekas
Hi all, > On Jan 15, 2020, at 06:22, Nicolas Grekas > wrote: > > Thank you for being open to the discussion and reconsidering! I\'ll do > my best to deserve the support I\'ve received :) Say, was there any resolution on this, one way or the other? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: A Hacker's Guide - Obsolete
> On Jan 25, 2020, at 07:23, Adiel Cristo wrote: > > I'm committed with learning the minimum necessary to having at least a > simple documentation, and I already started that, although with a long delay > from > what I planned due to other projects, but I'm working on it. That sounds like a lot of work; best of luck! Note also that there is https://phpinternals.net/ which I have found useful. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
> On Jan 16, 2020, at 06:47, Aleksander Machniak wrote: > > On 15.01.2020 21:15, Nikita Popov wrote: >> Yes, having a php.net account is sufficient. Additionally there are 28 >> users in the wiki in the "phpcvs" group, which I *think* means they can >> also vote. >> >> Based on master.php.net data, the number of people who are eligible for >> voting is approximately 1900. The usual turnout for RFC votes is more like >> 30. If it's something very controversial, maybe 100. >> >> People aren't kidding when they say it's easy to get an RFC vote -- but in >> reality, there's simply very little interest ;) > > This code > https://github.com/php/web-wiki/blob/9bc9ba2c3d2d0d26ab510e4959466ab8680b7de7/dokuwiki/lib/plugins/doodle/syntax.php#L226 > suggests above statements are false. *That's* the kind of thing I had I mind. Good find! Anyone have ideas on how (or from where) the `$INFO['userinfo']['grps']` values get populated? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
> On Jan 15, 2020, at 16:58, Levi Morrison via internals > wrote: > > We are predominantly volunteers, and should keep that in mind for > these kinds of things. Hear, hear. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
Hi -- > On Jan 15, 2020, at 14:15, Nikita Popov wrote: > > Yes, having a php.net account is sufficient. Additionally there are 28 > users in the wiki in the "phpcvs" group, which I *think* means they can > also vote. Ah, very good -- thanks for that! -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
> On Jan 15, 2020, at 14:12, Ben Ramsey wrote: > >> Ben (and others) -- your thoughts? Is it really as straightforward as >> "having a php.net account alone is enough to be eligible to vote” ? > > I wasn’t answering based on the rules. My answer is based on practice. Sure, though that practice has to be codified *somewhere*, otherwise there'd be no way for the wiki voting plugin to figure out who's allowed to vote. > AFAIK, everyone with a php.net account also has access to the wiki (you log > into the wiki using your php.net account), and therefore, also has the > ability to vote on RFCs. "As far as you know" is fine, but it would be nice to hear something more authoritative ... > Whomever has admin access on the wiki can provide more information. ... as you note. Can anyone besides Ben provide some insight here, perhaps even point to the code that determines if a wiki user is allowed to vote? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Who are the current eligible voters?
> On Jan 15, 2020, at 13:21, Ben Ramsey wrote: > > Everyone with a php.net account is able to vote. The public list is here: > https://people.php.net/ I don't think that's *quite* the case? As has been noted elsewhere, the rules are: > • People with php.net VCS accounts that have contributed code to PHP > • Representatives from the PHP community, that will be chosen by those with > php.net VCS accounts > • Lead developers of PHP based projects (frameworks, cms, tools, etc.) > • regular participant of internals discussions It's clear that the second point has not really taken hold, but the first point adds the caveat "that have contributed code to PHP", and that part *does* seem widely accepted. So unless I am wrong, merely having a php.net account doesn't appear sufficient -- code or docs contributions are an additional prerequisite to getting a vote. Ben (and others) -- your thoughts? Is it really as straightforward as "having a php.net account alone is enough to be eligible to vote" ? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Who are the current eligible voters?
Hi all, Apropos the Nicolas Grekas discussion on this list ... <https://externals.io/message/108111> ... and on Reddit ... <https://www.reddit.com/r/PHP/comments/eoltx1/nicolas_grekas_application_to_vote_on_rfcs/> ... I began to wonder who all is eligible to vote. Looking at people.php.net to see who has karma appears insufficient. For example, Ocramius <https://people.php.net/ocramius> has no karma but is eligible to vote; Fabien Potencier has voted as well but has no people.php.net page. So: is there a public listing of, or public code for deriving the list of, currently eligible voters? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: VCS Account Request: nicolasgrekas
(Copied from my Reddit comment earlier today.) > On Jan 14, 2020, at 08:15, Brent Roose wrote: > > Hi Peter > > Isn't it strange that someone like Nicolas doesn't get a vote? Symfony has > such a large impact on the PHP community, and Nicolas has such a large impact > on its development. Meanwhile people who contribute to the PHP docs, > sometimes completely estranged from modern day-to-day PHP development do have > a vote. Having high status in *one* community, does not necessarily transfer to having high status in *another* community (even if it's a *related* community.) So, the way to get voting rights on Internals is to actually contribute something to Internals -- whether code or docs. There has to be *some* barrier to to pass, that is specific to that community. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Static return type
> On Jan 8, 2020, at 05:42, Nikita Popov wrote: > > Hi internals, > > I would like to propose the following RFC, which allows using "static" as a > return type: > > https://wiki.php.net/rfc/static_return_type Very happy to see this. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
> On Sep 29, 2019, at 14:34, Stanislav Malyshev wrote: > > What this RFC provides framework > for is for initiating contentious and harmful personal attacks on people > because they "send too many emails" or question the RFC process or tell > somebody their idea for the RFC may not be the best one ever, and > equally grievous sins, and somehow make it look as if these people are > somehow against the community by the mere fact that somebody felt they > are "disruptive". There's no need of any "framework" for such thing. Hear, hear. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
> On Sep 23, 2019, at 09:16, Christoph M. Becker wrote: > > On 23.09.2019 at 15:55, Paul M. Jones wrote: > >> Ah, if only that were true. No, moderators have the power to act >> immediately, whereas any oversight regarding them can act only slowly, with >> deliberation, after long latency -- and even *then* only after long >> discussion, which the moderators themselves control. No, there is no way to >> "simply" dismiss a moderator. > > Please read <https://wiki.php.net/rfc/prevent_disruptions_of_conversations>. I have; I suggest do the same. With that out of the way: was there something in particular to which you wished to draw attention? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
Hey there -- >>> On Sep 20, 2019, at 01:25, Brent wrote: >>> >>> Moderators are no dictators >> >> Maybe, maybe not. >> >> But moderators can and do play favorites, banning or silencing one voice (of >> whom they disapprove) for the same things that they ignore from another >> voice (of whom they do approve). > > I feel like internals@ members have very little trust in their peers Perhaps; trust can be hard to come by. > and fear the world will burn and PHP will die because of moderators who try > to keep the discussions ontopic and civil. I think the fear is not of "the world burning" but of "being silenced." Further, "on-topic" is in the eye of the beholder; once there are moderators, their eyes are the only ones that matter. > Say five moderators are appointed and one turns out to be a bad one, a > dictator, a villain; We need not presume a villain or dictator. We need presume only groupthink -- a groupthink that biases moderator actions to err always on the same side (that is, the side populated by voices the moderators approve of). > the other four *and* the community at large can simply dismiss that bad one. Ah, if only that were true. No, moderators have the power to act immediately, whereas any oversight regarding them can act only slowly, with deliberation, after long latency -- and even *then* only after long discussion, which the moderators themselves control. No, there is no way to "simply" dismiss a moderator. >> Moderators, with the power to ban and to silence, become the owners of the >> project whose communications they moderate. By controlling the flow of >> information in a project, moderators control the status of the members in >> that project, and thereby control the direction of the project. > > I've been part of numerous online communities over the years, and this has > never, ever, been a problem anywhere. I've been a part of numerous online communities as well, and I have found it to be a problem quite often -- especially at the point of introduction of moderators. > Now PHP and internals@ might be the exception, though I think a little common > sense and human decency will get us a long way and might even make internals@ > productive again. I think there is quite a bit of "common sense and human decency" in play here already, even if not universal and uninterrupted -- nobody on this list is an angel, though some are more devilish than others. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
> On Sep 20, 2019, at 01:25, Brent wrote: > > Moderators are no dictators Maybe, maybe not. But moderators can and do play favorites, banning or silencing one voice (of whom they disapprove) for the same things that they ignore from another voice (of whom they do approve). Moderators, with the power to ban and to silence, become the owners of the project whose communications they moderate. By controlling the flow of information in a project, moderators control the status of the members in that project, and thereby control the direction of the project. -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Prevent disruptions of conversations
> On Sep 19, 2019, at 12:18, Dan Ackroyd wrote: > > Hi internals, > > Here is an RFC to "Prevent disruptions of conversations" > https://wiki.php.net/rfc/prevent_disruptions_of_conversations?do=edit Quoting the RFC: > The RFC process is currently the way that the PHP internals team make > decisions. "Make decisions" on what specific topics? Is there any articulable limiting principle here? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Object Initializer
> On Sep 12, 2019, at 09:00, Michał Brzuchalski
> wrote:
>
> Hi internals,
>
> I'd like to open discussion about RFC: Object Initializer.
>
> This proposal reduces boilerplate of object instantiation and properties
> initialization in case of classes without required constructor arguments as
> a single expression with initializer block.
>
> https://wiki.php.net/rfc/object-initializer
This reminds me of how Hack/HHVM would initialize object properties from
constructor parameters; I remember finding it very appealing.
IIRC, you would provide the property signature as a constructor parameter to
trigger the initialization:
```php
class Foo
{
protected int $bar;
public function __construct(protected int $bar)
{
}
public function getBar() : int
{
return $this->bar;
}
}
$foo = new Foo(1);
echo $foo->getBar(); // 1
```
Perhaps something like that is worth adopting here.
--
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Defining the PHP Group
Hi all, > Does anyone object to any of those words ? This strikes me as yet another attempt at a power grab, so many of the words are objectionable. However, this phrase will serve to show the weakness of the proposal: > Anyone may initiate an RFC for any subject. There needs to be an articulable limiting principle; without it, there can be no strong continuity, only the current passion of a mob. For example, this phrasing means the RFC system itself can be put up to vote, to be removed and replaced with something entirely non-democratic. Some things simply have to be off limits. What are those things? -- Paul M. Jones pmjo...@pmjones.io http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] ServerRequest and ServerResponse objects
On 2016-12-23 21:43:56 +, Andrea Faulds said: Hi, Since the $get, $post etc. properties are the same as $_GET and $_POST, does that mean they retain the same name mangling scheme? (See "https colon slash slash wiki dot php dot net slash rfc slash on_demand_name_mangling"* for details of that.) It would be nice to fix that eventually, and this would be a place where we could do so without breaking backwards-compatibility. *Sorry about spelling it out like that. Apparently, the mail server thinks this link is spam. (I'm trying to post via Usenet, since mailing list messages on this thread have not come through to me. This is a copy of an email I sent to Andrea directly.) I presume the answer is "yes" because the properties are populated directly from $_GET and $_POST. If there is some patch that might be applied to un-mangle things, and you think this is the place to do it, I cannot imagine John Boehr or I would refuse a patch. -- pmj -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Evaluate arguments of new for classes without constructors
> On Mar 12, 2016, at 11:27, Sara Golemon wrote: > >> HHVM does not implement "new" in this way, they always evaluate the >> arguments. >> > Which, if it helps, means that we already know a lot of frameworks > /don't/ break as a result of fixing this behavior. > >> As this is technically a BC affecting change (even if of the lowest >> impact), I'm running it past the list first. >> > Technically a BC break that justifies waiting till a major version. > Given the extremely specific requirements to hit this edge case > however, passing side-effect args to a non-existent constructor, I > personally think a minor version is fine. Of curiosity, what effect (if any) might this have on ReflectionClass::newInstance(), ::newInstanceArgs(), and ::newInstanceWithoutConstructor()? (I ask because some existing DI systems, such as Aura.Di, rely on those for creating objects.) -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Contributor Guidelines, and Updates to Code of Conduct progress
Hi Derick, > On Feb 9, 2016, at 06:33, Derick Rethans wrote: > > Hello! > > Things have quieted down around the Code of Conduct and Contributor > Guidelines process For my part, at least, things are in "hibernation" until the wiki is updated with the new draft. Meanwhile: > - I had a call with the Drupal Community Working Group - as suggested by > Larry Garfield. Stanislav was on the call as well. Is there a transcript or recording of the call? I'm very interested to know what transpired. > - We should be reluctant to limit the scope of the Code of Conduct and >Contributor Guidelines. What is the reasoning behind this? > - A Code of Conduct without *any* 'teeth' would not be beneficial. Why was that? > - We should start with suggesting/nominating people for the Mediation >Team *before* deciding on the procedures and guidelines that >they should mediate around. The underlaying reason is that if the >team is known upfront, there ought to be more understanding for the >general developer community. Or in other words, there should be no >reason that "I would only put my friends on it". I think that presumes the people making up the Team will be present for all time thereafter, and never replaced. Indeed, it reinforces the idea that the political persuasions of the Team members will be the determiner of how the Code is enforced, if one is ever adopted. Since we cannot know in advance who will be in place *after* the first Team, I opine the rules should not be Team-member-dependent. >I do however have a few people in mind that I will reach out to >privately, to see whether they are interested. If you have any >suggestions for people that you consider reliable, considerate, and >empathic, please reach out to them yourself, or let me know and I >will. I'm reliable, considerate, and empathic toward accused persons. Does that count? > - I combined the three bits of text around mailinglist posting >guidelines into the Contributor Guidelines > > https://github.com/derickr/php-community-health/commit/7c55d1dd407524cdab593b885e6b3101bf590769 > > I feel that the "Contributor Guidelines" are now in a reasonable shape > to do a quick poll to gauge acceptability. As this is not a formal RFC > vote, it's simply done through an online poll: (The poll was later moved to the wiki at <https://wiki.php.net/adopt-code-of-conduct/guidelines>.) While the narrative itself is rather generic, there are several problems with the Guidelines. Others have mentioned some of them in various replies to this thread. For me, the biggest problem is that the Guidelines presume that every RFC can be made into something useful and/or desirable. There is no allowance made for declining an RFC as unworkable or unacceptable from the beginning, politely or otherwise; for example, something that is against the "vision" (however interpreted) of PHP in the first place. Some things are best rejected out-of-hand at their beginning. Some may not see that as "constructive"; but then, what is "constructive" depends on what you construct. Derick, can you imagine there might ever be a time when an RFC should be turned down on its face? If so, in which cases do you think that would apply? If not, why not? Second, the Guidelines lack definitions. They say, "Debate the technical issues, and ideas behind them, but never attack the person holding them." Derick, what does "attack" mean in this context? In lieu of a definition, do we have an actual example from PHP-Internals that shows an "attack" in that sense? If there is, it should be linked. If there is not, then why do we think "attacks" of this kind are a problem to be addressed? Finally, these are Guidelines, but for whom? Is their violation actionable? If so, by whom, and in what circumstances? If not, then the Guidelines should say so. I have other issues, but those will do for now. -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> On Jan 24, 2016, at 16:48, Dan Ackroyd wrote: > > A significant number of technical RFC discussions have been less > productive than they should be, due to people repeatedly sending > emails against an RFC, that repeat what they have already said, which > is not a productive use of anyone's time, and makes people (including > myself) not want to put forward ideas, or to participate in the > discussions. Or repeatedly sending emails *for* an RFC. ;-) That is, if one thinks others should make their *disagreement* known only once, perhaps one should make one's own *agreement* known only once. -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> On Jan 21, 2016, at 09:46, Derick Rethans wrote: > >> - There is no mechanism or ability for one to confront ones accuser > > That is a tricky one. In my opinion, in the case of abuse as pointed out > in the draft CoC, I think this is fair, and necessary that we all for > reports of abuse in private, and with secrecy. Without it, an accusor is > likely immediately going to be lambasted by the perpetrator. Here we have the core of (yet another) problem: presumption of guilt. The "accused" is casually referred to as the "perpetrator." This is *exactly* why the accused needs to be able to confront the accuser. The common reply here is to say "oops, sorry, I meant to say 'the accused'". I don't think that's true; it's a wink-and-a-nod, a recognition that one has revealed their true thoughts: all accusations are to be believed. Except, of course, the ones that are not to be believed, and those will (strangely enough) line up with the political beliefs of the enforcers. Because it is a political document, the Contributor Covenant is *intended* to work that way. That is only one of the many reasons the Contributor Covenant, and all documents like it, should be removed in toto from any Code of Conduct discussion. -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> On Jan 21, 2016, at 09:59, Pádraic Brady wrote: > > Hi, > > On 21 January 2016 at 14:33, Allan MacGregor > wrote: >> Padraic, >> >> Taking a step back, instead taking a knee-jerk reaction; I think Kevin >> brought up a valid point. Is very clear that there are certain actors that >> are pushing for a specific version of this code of conduct to use it as a >> political tool. > > The RFC has actual text, which can be read, examined and discussed. > There is no need whatsoever to drag in anything beyond unless directly > relevant to the text at hand. Personal attacks on people who support a > COC, or do not support a COC, aren't productive. If there is a > political plot to undermine whatever in PHP, then please do support > this by quoting from the RFC. That's a nice try, but since the Contributor Covenant is a political document, the politics of those who favor it are fair game. Also, your attempt to characterize "quoting someone's own words" as "personal attacks" is noted. -- Paul M. Jones pmjone...@gmail.com http://paul-m-jones.com Modernizing Legacy Applications in PHP https://leanpub.com/mlaphp Solving the N+1 Problem in PHP https://leanpub.com/sn1php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [Re-proposed] Adopt Code of Conduct
> On Jan 20, 2016, at 13:04, Derick Rethans wrote:
>
> Hi,
>
> I've decided to re-propose the CoC RFC.
Is it a violation of the RFC rules to skip step 1 ("Email
internals@lists.php.net to measure reaction to your intended proposal") and go
straight to step 3 ("Create the RFC") ?
<https://wiki.php.net/rfc/howto>
At the very least, it seems like an initial email needs to be sent before
putting the RFC on the wiki.
--
Paul M. Jones
pmjone...@gmail.com
http://paul-m-jones.com
Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp
Solving the N+1 Problem in PHP
https://leanpub.com/sn1php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
