Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On May 5, 2025, at 16:36, Máté Kocsis wrote: > > Hello Internals, > > After more than a hundred emails refining even the tiniest details, we have > reached a point where I'd like to call for a vote. > I know that the new API still doesn't support many use-cases, it still has

Re: [PHP-DEV] Concept: Lightweight error channels

Hi all, > On May 1, 2025, at 09:29, Levi Morrison wrote: > > On Tue, Apr 29, 2025 at 9:48 AM Paul M. Jones wrote: >> >> >> >>> On Apr 27, 2025, at 07:26, Niels Dossche wrote: >>> >>> Regarding performance however, rather than int

Re: [PHP-DEV] Concept: Lightweight error channels

> On Apr 27, 2025, at 07:26, Niels Dossche wrote: > > Regarding performance however, rather than introducing yet another completely > new concept to do almost the same thing, why not try to improve exception > performance instead? > > I just opened a PR that makes instantiating exceptions m

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté and all, tl;dr: I argue against Ignace's objections to splitting the URI class into two classes (one that retains raw URI values and another that normalizes values as-it-goes). Jump to the very end for a discussion regarding the with() methods (search for the word "asymmetry" h

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On Apr 27, 2025, at 16:47, Máté Kocsis wrote: > > Hi Tim, ... >> So it seems to be safer to use the naming without the `raw` and then in >> the documentation explain what happens with useful examples, just like >> the RFC already does. > > We discussed this off the list, an

Re: [PHP-DEV] DokuWiki password reset failed?

> On Apr 24, 2025, at 04:32, Christoph M. Becker wrote: > > On 24.04.2025 at 03:21, Paul M. Jones wrote: > >> I just reset my `pmjones` password on DokuWiki, but the password it sent is >> not letting me in. Is there something else I need to do? > > Since yo

[PHP-DEV] DokuWiki password reset failed?

Hi all, I just reset my `pmjones` password on DokuWiki, but the password it sent is not letting me in. Is there something else I need to do? Sorry for the hassle, and thanks for your patience. -- pmj

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, A one-off comment about the exceptions: The RFC posits that _Uri\UriException_ extends _Exception_, and _Uri\InvalidUriException_ extends _UriException_. However, pre-existing userland solutions to the URI problem lean more heavily on the native PHP _InvalidArgumentException_,

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

> On Apr 17, 2025, at 15:58, Tim Düsterhus wrote: > > Hi > > On 4/17/25 22:47, Paul M. Jones wrote: >> As such, the _InvalidUriException_ would better extend from _LogicException_. > > No. There is a de facto policy of “not using SPL exceptions in new co

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Ignace & Maté & all, > On Mar 19, 2025, at 16:18, Ignace Nyamagana Butera > wrote: > > https://github.com/bakame-php/aide-uri/blob/main/src/Uri.php > While implementing the polyfill I am finding easier DX wise to make the > constructor private and use instead named constructors for instant

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, > On Mar 25, 2025, at 03:45, Máté Kocsis wrote: Regarding Rowbot slowness compared to the RFC: > I can only assume that the excessive usage of objects makes the library much > slower than what's possible > even for a userland library (obviously, an internal C implementation w

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi all, > On Mar 20, 2025, at 01:31, youkidearitai wrote: > > -- Forwarded message - > From: youkidearitai > Date: 2025年3月20日(木) 14:41 > Subject: Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ? > To: Paul M. Jones > > > 2025年3月19日(水) 2:52 Pau

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi Rowan & all, > On Mar 22, 2025, at 10:20, Rowan Tommins [IMSoP] wrote: > > On 21/03/2025 11:17, Tim Düsterhus wrote: >> >> I am not sure if that signature makes sense and if the proposed >> functionality fits into mbstring for that reason. IRIs are defined as UTF-8, >> any other encoding r

Re: [PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi Tim & all, > On Mar 21, 2025, at 06:22, Tim Düsterhus wrote: > > Am 2025-03-18 18:48, schrieb Paul M. Jones: >> $iriPath = '/heads/' . rawurlencode($val) . '/tails/'); >> assert($iriPath === '/heads/fü bar/tails/'; // false > > Fr

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté, > On Mar 18, 2025, at 15:15, Máté Kocsis wrote: > > There's no way I would have written an implementation from scratch. I'm using > the url module of the Lexbor C library (https://github.com/lexbor/lexbor/) > for handling WHATWG URLs. It's already bundled in core, and it's also batt

[PHP-DEV] Potential RFC: mb_rawurlencode() ?

Hi all, The discussion around WHATWG-URL on this list, as well as my work coordinating Uri-Interop , lead me to think PHP needs a multibyte equivalent of rawurlencode(). Broadly speaking, as far as I can tell: - For an RFC 3986 URI, delimiters need to

Re: [PHP-DEV] [RFC] [Discussion] Add WHATWG compliant URL parsing API

Hi Maté and all, There is a pre-existing userland implementation of WHATWG-URL at . Packagist reports 600K+ downloads . It is from Trevor Rowbotham, who is acknowledged in the WHATWG-URL specification itself <

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

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 u

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 t

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

Re: [PHP-DEV] Analysis of property visibility, immutability, and cloning proposals

(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/sn1p

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://lea

Re: [PHP-DEV] [RFC] Restrict $GLOBALS usage

lass 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

Re: [PHP-DEV] Attribute Syntax Revote

... > 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...@pmj

[PHP-DEV] Attribute Syntax Revote

f 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

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. Jone

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

n 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

egular. 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.

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

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

st 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/m

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 hav

Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change

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

s 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. J

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 &

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: >>>> >>>&g

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

Re: [PHP-DEV] [RFC] [Discussion] Shorter Attribute Syntax Change

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

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 o

Re: [PHP-DEV] [RFC][DISCUSSION] Change var_export() array syntax touse short hand arrays

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://l

[PHP-DEV] [RFC] [EPILOGUE] Server-Side Request and Response Objects (v2)

land 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 hu

[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. Th

Re: [PHP-DEV] [RFC] Change default PDO error mode

ions 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: h

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-jone

[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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

/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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

27;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 Developmen

Re: [PHP-DEV] Capturing reasons for votes for historical sake?

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*

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

o 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 Mod

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

er['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 Moder

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 yo

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

y 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

tate, 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 Proble

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

ike 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 d

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 propo

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: >

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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...

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

o 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

e 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...@pm

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: > > ...

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

s 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

hen 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 m

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

nted 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 functions." So it's not that the RFC proposes a "simpler" way to use the superglob

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

ation 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.co

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 eno

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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)

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 c

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

t; 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. Th

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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 - P

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

g 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

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 `$_GE

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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 >>> ... ? >> >>

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

nter-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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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? -- Pa

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

;> 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

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 http

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

::__construct($globals, $content); if ($this->forwarded) { $this->clientIp = // ... } } public function getClientIp() { return $this->clientIp; } } You could do that for all your custom calcula

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

ist 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)

cts: 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 htt

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

hy 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 Legac

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

hough 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 Inter

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

o 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://lea

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

t 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

o 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

Re: [PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

'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

[PHP-DEV] RFC: Server-Side Request and Response Objects (v2)

acement 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://pau

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. Jone

Re: [PHP-DEV] Re: A Hacker's Guide - Obsolete

g 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 PH

Re: [PHP-DEV] Who are the current eligible voters?

alse. *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://l

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 Applicatio

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. Jone

Re: [PHP-DEV] Who are the current eligible voters?

ht 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

Re: [PHP-DEV] Who are the current eligible voters?

ns 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 P

  1   2   >