Re: [PHP-DEV] List of attributes

[Paul Jones]

> On Oct 30, 2020, at 14:28, Rowan Tommins  > wrote:
> 
>> 3. Vote to switch to a less verbose syntax [...]
>>The downside is that...
> 
> Let me stop you there. The downside is that a mob of Internals regulars will 
> come to your house and lynch you for asking them to vote on the same thing 
> yet again. It just ain't gonna happen.

Yes, because we voted repeatedly until the voters "got it right" -- and now 
there cannot ever be another vote on it again.


-- 
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] Proposal for a RFC

[Paul Jones]

> On May 4, 2019, at 11:08, Kalle Sommer Nielsen  wrote:
> 
> Hi
> 
> Den lør. 4. maj 2019 kl. 17.58 skrev Steven Wade :
>> 
>> Hi Internals team!
>> 
>> I have an idea for a feature that I'd love to see in the language one day 
>> and wanted to run the idea by you all.
>> 
>> The idea is to add a new magic method "__toArray()" that would allow a 
>> developer to specifiy how a class is cast to an array. The idea is the same 
>> mentality of __toString(), but, for arrays.
> 
> While this sounds great and all, I do wonder about the implications it
> may have on the already existing behavior of type casting an object
> into an array which returns current public/protected/private property
> values.

I find it easy to imagine that objects not implementing __toArray() would 
continue to exhibit that behavior.


-- 
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] Proposal for a RFC

[Paul Jones]

Hi Steven,

> The idea is to add a new magic method "__toArray()" that would allow a 
> developer to specifiy how a class is cast to an array. The idea is the same 
> mentality of __toString(), but, for arrays.

I'd like to see this 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: Re: [PHP-DEV] [VOTE] Deprecate left-associative ternary

[Paul Jones]

Hi all,


> On Apr 24, 2019, at 11:27, Nikita Popov  wrote:
> 
> To better judge the BC impact here, I've analyzed the top 1000 composer
> packages for this pattern. The results are here:
> https://gist.github.com/nikic/b6214f87b0e4a7c6fe26919ac849194f

I *love* research like this. Really nicely done. Can you share how you 
accomplished 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: Locked Classes

[Paul Jones]

> On Mar 10, 2019, at 13:35, Rowan Collins  wrote:
> 
> Hi all,
> 
> I'd like to present a new RFC for "locked classes": classes which restrict 
> dynamically adding or removing properties from their instances.

Nice. This would help enforce at least one element of immutability in userland; 
namely, not having to define `final public function __set()` and `final public 
function __unset()` to prevent adding and mutating undefined properties.



-- 
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: RFC Workflow & Voting (2019 update)

[Paul Jones]

All,

I have managed to avoid commenting on PHP-FIG since the group was dissolved, 
then re-constituted under the same name, without my participation as one of its 
original founding members.

However, I cannot let this phrasing pass:

On Feb 1, 2019, at 10:30, Larry Garfield  wrote:

> FIG today is a very different organization.  It does not 
> claim any authority or official-ness beyond "a lot of people listen to our 
> recommendations", which is objectively true.

Larry is trying to play both sides here with plausible deniability. Quoting him 
from https://www.sitepoint.com/the-past-present-and-future-of-the-php-fig/ :

> FIG has effectively become the standards body for PHP. It took time for it to 
> earn it, but it did, thanks to the work of dozens of people, both FIG members 
> and not. A [Reddit 
> thread](https://www.reddit.com/r/PHP/comments/3wownq/how_do_you_see_the_phpfig/)
>  started last January showed that, while not universal, there was a clear 
> preference for FIG to step up and accept that role formally.

Either Larry feels that FIG is effectively a standards body, or he does not.

And now that I have spoken, I may be more to say on the matter -- but not just 
yet.


-- 
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] abolish narrow margins

[Paul Jones]

> On Jul 11, 2018, at 12:10, Sara Golemon  wrote:
> 
> On Wed, Jul 11, 2018 at 12:41 PM, Joe Watkins  wrote:
>> I'd like to bring https://wiki.php.net/rfc/abolish-narrow-margins to vote
>> in the very near future ...
>> 
>> We discussed it a year ago, and discussion died down to nothing (possibly
>> because it was sidetracked); If there are no objections I'll bring it to
>> vote in the coming days ...

Since you brought it up ...

> "The current political climate of Earth

It's probably less "Earth" and more "Western civilization."

> votes that are won by narrow margins build resentment among voters

Well, certainly among some. I have to wonder if this is a reference to the 
author's favored political outcomes being thwarted.

> can lead to instability in the ecosphere

The "ecosphere" of Earth? That's an interesting assertion. I wonder if it's 
true.

> and could be considered harmful to democracy.

There's a long list of things that "could be considered harmful to democracy."

In any case, are we turning this list into a political forum? Because I for one 
can do without it here. I find it in plenty of other places.

I don't have any more to say on that aspect of this topic right now, unless and 
until someone else here sees fit to continue it -- in which case, I'll be happy 
to respond.


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





-- 
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] Mixed type

[Paul Jones]

> On Jun 30, 2018, at 15:17, Sara Golemon  wrote:
> 
> I'm not super excited about this RFC because, as you say, this information 
> could be easily encoded into the docblock for the function/method.

I would enjoy a 'mixed' typehint for exactly that reason; i.e., that I don't 
have to put it in a docblock.

Given this method ...

   public foo(string $bar, int $baz) : void { ... }

... I don't need any docblock at all for the params.

But given *this* method ...

   public foo(string $bar, int $baz, $dib) : void { ... }

... I find myself wanting (for completeness' sake) to add a docblock indicating 
the $dib typehint:

   /**
* @param mixed $dib ...
*/
   public foo(string $bar, int $baz, $dib) { ... }

... and *then* the docblock looks unusual to me, and I want to fill out all the 
rest of the params in the docblock.

Yes, I'm aware that may be idiosyncratic. Even so, being able to do this ...

   public foo(string $bar, int $baz, mixed $dib) { ... }

... relieves that bit of docblock dissonance. If it does so for me, I bet it 
would do so for 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





-- 
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] Immutability

[Paul Jones]

> On Feb 25, 2018, at 12:59, Silvio Marijić  wrote:
> 
> Here is link to tweet 
> https://twitter.com/SilvioMarijic/status/965564630071300096

After having read that, I think "immutable" is still perfectly reasonable.


-- 
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] Immutability

[Paul Jones]

> On Feb 25, 2018, at 11:29, Silvio Marijić  wrote:
> 
> I had discussion on Twitter regarding semantics of keyword 'immutable'.

Can you link to the discussion? I am interested to read 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][DISCUSSION] Immutability

[Paul Jones]

Hi Silvio,

I like the RFC.

* * *

I would like to see arrays allowed as immutable properties.

In  I wrote that arrays are "probably 
not practical in most situations" because you have to "recursively scan through 
array properties to make sure that they contain only immutable values".

However, I think if the scanning happens at the C level it is not such a 
burden. John Boehr implemented it for the immutable ServerRequest object in 
ext-request  and it has worked well.

If you do allow arrays, they would have to follow the same rules as the 
immutable object.

Alternatively, perhaps an ImmutableArrayObject would be a good addition or 
followup to the RFC.

* * *

Some further points to harden the implementation:

- I see that resources and references are disallowed (which is good). If you 
have not already done so, you may wish to disallow streams as well.

- You might want to disable setting of undefined public properties, so that you 
cannot "add" mutable public properties to the immutable object.

- Disable the constructor after it has been called, so the object cannot be 
"re-constructed" in place.

* * *

That's all I can think of for now. Thanks for putting this together.


-- 
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] var_export() array format

[Paul Jones]

> On Feb 17, 2018, at 18:27, Andreas Hennings  wrote:
> 
> What we can do is add a third parameter with flags.

Big +1. When writing tests and setting the $expected value, one of the 
constantly recurring drudgeries is reformatting the correct var_export($actual) 
output from arrays to match the surrounding code style. This would reduce that 
tedium by an order of magnitude.

-- 
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] Mailing list moderation

[Paul Jones]

> On Jan 3, 2018, at 12:59, Joe Watkins  wrote:
> 
> Let's remember that there are a large number of people on the sidelines that 
> are not subscribed to the list directly, but choose to use news readers, or 
> the excellent externals.io; They may not able to filter messages from any 
> individuals, so they are in effect forced to navigate through these 
> "contributions" from problematic posters. That's not fair to them, at all. 
> All of the conversations here are a matter of public record, not only 
> existing in your mail client, or inbox, or whatever ... We can and should be 
> eliminating noise from that public record.

It is indeed excellent. Perhaps this is an opportunity to create 
"expurgated.externals.io" that is under the control of whoever creates & 
manages it, to filter "noise" there so that others may peruse it in what they 
consider to be peace.

That's three postings for me on this topic today, which is probably a bit much; 
I'll leave it at that 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] Mailing list moderation

[Paul Jones]

> On Jan 3, 2018, at 12:35, Joe Watkins  wrote:
> 
> You don't get to conduct yourself however you want without consequence.

Sure. The question then, is, what is the proper consequence? I hold that it is 
not "banning" or "suspension" (which may or may not actually be within the 
delegated powers of anyone on this list). Instead, it is "to be ignored, by 
those who choose to ignore you."


-- 
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] Mailing list moderation

[Paul Jones]

> On Jan 2, 2018, at 12:29, Dustin Wheeler  wrote:
> 
> On Tue, Jan 2, 2018 at 12:19 PM, Levi Morrison  wrote:
>> 
>> I doubt we have any official procedures. I agree with the proposed
>> suspension as long as the suspension for a set amount of time; I
>> believe in giving people a chance to reform. If they can't reform...
>> well then I'm fine with an indefinite suspension.

I am not in favor of anyone else deciding for me that I am not allowed to see 
Tony's (or anyone else's) messages on this list. I can make that decision 
myself, and revisit that decision myself should I choose.

If someone dislikes Tony's commentary for any reason (or no reason!) they are 
free to filter his messages themselves -- and then unfilter his messages when 
they see fit.


-- 
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] A validator module for PHP7

[Paul Jones]

> On Sep 4, 2017, at 18:06, Marco Pivetta  wrote:
> 
> On Mon, Sep 4, 2017 at 8:56 PM, Crocodile  wrote:
> 
>> In most cases users would like more than just valid/invalid, i. e. which
>> particular rule(s) failed and also human-readable error messages. As of
>> simple validation that is almost always at hand, filter_* functions do a
>> good job, although I agree that they could be better. I, for one, would
>> like to see a full-featured validation as part of PHP. However, this RFC
>> only looks like a slightly better version of filter_* functions, that is,
>> the new module will provide almost the same functionality but with a
>> different interface. I would vote against it.
>> 
> 
> And also, it would need to be better than all of these to be worth writing
> it in C:
> 
> https://packagist.org/search/?q=validator

And these as well: https://packagist.org/search/?q=filter

(Or at least have some level of parity.)


-- 
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] Re: Changes to SuperGlobals for PHP 8 (was: somethingabout session_start...)

[Paul Jones]

> On Jul 29, 2017, at 11:58, Andrea Faulds  wrote:
> 
> Come to think of it, can we fix $_FILES while we're at it? :p

Not to be a broken record here, but this is something the `request` extension 
does as well.

In other words, a starting point for a lot of this work already exists.


-- 
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] Changes to SuperGlobals for PHP 8 (was: something about session_start...)

[Paul Jones]

> On Jul 29, 2017, at 05:27, Dan Ackroyd  wrote:
> 
> Designing classes/interfaces to be correct the first time is a really
> difficult thing to do, and then maintaining classes/interfaces is hard
> as any change to a method is a BC break.

Having done it several times before in userland helps.  Presenting the 
superglobals as read-only properties does the trick for the `request` 
extension; it's even simpler than using methods.


-- 
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] Changes to SuperGlobals for PHP 8

[Paul Jones]

> On Jul 28, 2017, at 10:11, Sara Golemon  wrote:
> 
> 3. I'm definitely not decided on what I'd like from default session
> behavior. An error isn't out of the question, for sure.

If this kind of big change is being contemplated, I would very much be in favor 
of decoupling the various combined elements of sessions. In particular, 
decoupling the auto-reading and auto-sending of cookies from the storage 
interactions.

Also, the "request" extension (and its related RFC) may have some use here, as 
it attempts to address the readable nature of superglobals.

- http://pecl.php.net/package/request
- https://wiki.php.net/rfc/request_response


-- 
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] samesite cookie implementation

[Paul Jones]

> On Jul 18, 2017, at 08:37, li...@rhsoft.net wrote:
> 
> 
> 
> Am 18.07.2017 um 15:23 schrieb Frederik Bosch | Genkgo:
>> Hi Andrey,
>> Thanks for your feedback. If we are going to wait for http_cookie_set, then 
>> my guess will be that it will take a while before we see samesite cookie 
>> implemented. While I totally agree there is need for a new function with a 
>> better API, I fail to see why that would mean we cannot have a samesite 
>> argument in the set(raw)cookie functions now. The RFC is in line with the 
>> design of these functions.
>> With regard to browsers not implementing it, let me quote the currrent 
>> documentation on the httponly argument. "It has been suggested that this 
>> setting can effectively help to reduce identity theft through XSS attacks 
>> (although it is not supported by all browsers), but that claim is often 
>> disputed." Basically it says that it is not supported by all browsers, but 
>> provides help reducing XSS attacks. I don't see the difference with samesite.
> 
> which browser in 2017 does not support 'httponly'?
> that was true a decade ago, now that parapgraph in the docs is just FUD

(/me nods)

Perhaps the same will be true for "samesite".


-- 
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] Namespaces in Core

[Paul Jones]

> On Feb 6, 2017, at 13:50, Peter Cowburn  wrote:
> 
> a vote which essentially is about adopting
> namespaces in core, via new library RFC, is not the way to go about
> changing our coding standards.  In short, I don't want to the see the
> situation where this extension gets merged in to 7.2 (which it should be
> :)) only to have someone ask, "what about the 'php' top-level namespace?"
> and we all shrug and mutter, "too late" under our breaths.

I would not have noted this if you had not said something. Thank you for doing 
so.


-- 
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] Deprecate and Remove Bareword (Unquoted) Strings

[Paul Jones]

> have drafted an RFC rather than trying to fit all the detail into one e-mail: 
> https://wiki.php.net/rfc/deprecate-bareword-strings
> 
> Please read my proposal, and let me know your thoughts. I have placed the RFC 
> "under discussion", but will be happy to modify it based on feedback, and am 
> in no haste to put it to a vote.

Happy to see this behavior removed, and appreciate the incremental approach. 
E_WARNING seems appropriate. Thanks for proposing it!


-- 
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] Not autoloading functions

[Paul Jones]

> On Jan 20, 2017, at 01:04, Rasmus Schultz  wrote:
> 
> Just a quick thought.
> 
> Since the autoloading functions proposal is stalled, how about allowing for
> import of static functions instead?
> 
>use function Foo::bar;
> 
>bar(); // calls Foo::bar()
> 
...
> at least we can move ahead
> and leverage existing code without changes or BC breaks. It's not all bad.
> It's better than nothing perhaps? :-)

I find this intuitively appealing. It's an incremental change with tangible 
benefit in an imaginable timeframe, as vs a dramatic change in an unknowable 
timeframe.

However, I am not an internals expert, so I'll leave it to them to say how big 
a deal it would be to implement, and what the drawbacks are.


-- 
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][Discussion] ServerRequest and ServerResponse objects

[Paul Jones]

Hi Arvids,

> On Jan 10, 2017, at 17:22, Arvids Godjuks  wrote:
> 
> I would also add the support, bug and feature issues that will definitely 
> crop up with such an interface. If there is a major bug, flaw or security 
> issue, getting it fixed is going to be a problem, because as we know, the 
> adoption of PHP is nowhere near instantaneous and it can be years before you 
> get the actual fix into the servers your project/projects are running on, and 
> you can't do anything about this.

(/me nods) That particular problem is not specific to this RFC, though.  It's 
true for anything that gets into PHP.


> There are also questions - a 1GB upload comes in, will interface implement 
> streams or some other way of handling that? Or there is a 200MB gallery 
> upload of images, with how most hosts set up their memory limits, I would 
> imagine this would just run out of memory. And all that stuff.

Interesting -- what happens *now* without the ServerRequest RFC?  If a 1GB 
upload comes in (or a 200MB gallery upload of images), then it gets dealt with 
under the RFC in exactly the same with PHP deals with it right now. That is: 
probably by attempting to store the uploads on disk, then exposing the file 
information via $_FILES.


> It's a way bigger job than I think the proposing person thinks, and it needs 
> major support from the project maintainers, because I'm 146% sure one person 
> will not be able to do it all and maintain it for next 10 years before it 
> becomes integral part of the core...

It might well be a way bigger job than John & I think. However, I do have to 
point out that the vast majority of the functionality is pretty 
straightforward, and not terribly complex.  It's certainly not at the PDO, XML, 
Filter, etc. level of intricacy.


> This is something that needs to be tested and runned as a module for quite 
> some time before it is stable enough to be in the core anyway - just see what 
> happened to PDO  - as far as I know, no one really wants to touch it, it's a 
> mess.

I can't speak to PDO, but I can say that APIs very similar to the one proposed 
in the RFC have been around for a long time, implemented by many different 
developers in many different systems. This RFC represents a summation and 
condensation of those behaviors.


-- 
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][Discussion] ServerRequest and ServerResponse objects

[Paul Jones]

> On Jan 7, 2017, at 15:41, Joe Watkins  wrote:
> 
> That doesn't sound like a positive consensus that this is a good idea, it is 
> rather the opposite.

Not to get into interpretations of comments, but while I agree that there were 
one or two actual negatives, they were predicated on a misunderstanding of the 
purpose of the RFC. As such I took them as neutral, rather than negative. The 
remainder were questions or comments, and not negative ones.

Either way, I think we can see from reactions here since then (and elsewhere) 
that there is some level of positive interest in the RFC as presented, as well 
as some healthy technical questioning. I'm happy to hear both.


-- 
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][Discussion] ServerRequest and ServerResponse objects

[Paul Jones]

Hi all,

Replying to both Marco Pivetta and Joe Watkins here, as some of their critiques 
overlap. I apologize in advance for the length of this email.

* * *

On Jan 6, 2017, at 10:47, Marco Pivetta  wrote:

> Bundling the [PSR-7] interface is no biggie, so I suggest steering away and 
> going that way

It's a bigger deal than one might think. But again, I have no desire to 
highlight the negatives of PSR-7 in this discussion.

I'd much rather discuss the RFC on its own merits, which Marco does next:

> There are several technical issues too:
>
>  * A magic constructor that fetches data from global state: add a factory for 
> that, leave the constructor open for modifications or new instantiation ways, 
> or make it private.

I get that. John and I tried both variations, and found that the static-factory 
version was clunkier than we expected. For example, if ServerRequest uses a 
static factory, then users extending the ServerRequest class will additionally 
have to write their own factory. Having the constructor just "felt" better when 
we used it. But, I am willing to revisit that decision if needed.

As far as global state: yeah, I hear you. Since ServerRequest is intended to 
encapsulate the superglobals, it seemed reasonable to have it default to 
copying the superglobals internally. Note that the `__contruct(array $globals = 
[])` signature allows for a complete override of whatever you want. (The 
vagaries of JIT population come into play here as well.)


>  * Magic read-only properties that go against the language semantics: make 
> 'em accessors, or do whatever you want, but don't invent new language 
> semantics just for your own extension.

You're right that it's not often seen. However, public read-only properties are 
not a new invention for this RFC. They already exist, such as in 
PDOStatement::$queryString .

FWIW, the use of a public read-only property turns out to be very practical in 
daily work. Instead of variations on ...

$request->getPost(); // returns the whole array
$request->getPost($key); // returns a value in the array
$request->getPost($key)[$subkey]; // returns a sub-value in the array
$request->getPost($key, $default); // returns a value, or a default if not 
present

... you work with the property like any other array:

$request->post;
$request->post[$key];
$request->post[$key][$sub];
$request->post[$key] ?? $default;

It's just that the property is read-only, and you get an exception if you try 
to change it (same as with PDOStatement::$queryString, if I recall correctly.)



>  * A series of non-exhaustive properties that give some "helper" API to see 
> if it's XHR or not, violating basic SRP. Are you abstracting a request or 
> what you want to do with the request? You can define separate utility 
> functions for that. Yes, functions.

/me nods

They are definitely non-exhaustive; the list of properties was put together 
from several reference projects that have classes similar to ServerRequest 
(more on that below).

When some of those projects had a use for for a particular value, I figured it 
made sense to include it here. (If you or others want to provide patches to 
make it more exhaustive, so much the better!)

As for being a violation of the single-responsibility principle, I don't know. 
It seems reasonable to think that if the object contains (e.g.) 
`$request->server['HTTP_FORWARDED']`, it might do well to contain a parsed 
version of the same information as an array in `$request->forwarded`.


>  * As per current API, I'd expect the ctor to throw an exception when used 
> outside the web SAPI context

I will defer to John Boehr on this one. I do wonder how difficult that would 
make it to test at the command-line, or include in command-line testing 
environments (e.g. PHPUnit).


>  * You use the *with* prefix for setting values, while you know exactly that 
> *with* was used to differentiate from a mutable and a non-mutable API in the 
> existing request abstractions: this makes things confusing again

I'm sorry, I don't understand the criticism here. The `ServerRequest::with*()` 
methods do in fact provide an immutable API (a pretty strict one at that). That 
is, they return a new copy of the ServerRequest object with the changed values, 
leaving the original copy unchanged. Maybe I'm not getting what you're saying 
... ?


>  * There's no interface for these classes, and they are not marked as final, 
> as far as I can see. This means that users will extend them (unwise choice), 
> and with that they will have a class with reflection bits in the extension 
> (extremely bad idea!). An interface and final are needed here.

Extensibility is an intended option. Many classes in PHP can be extended, to 
good effect (e.g., PDO).  But I am willing to be hear about why this is a bad 
call -- can you expand on your reasoning?

> I am obviously defensive and biased here

Sure; anyone would be. Th

[PHP-DEV] [RFC][Discussion] ServerRequest and ServerResponse objects

[Paul Jones]

(This is a re-send, on a new thread, of the message originally posted at 
 with some minor edits. The original 
was apparently not delivered to the entire list.)



Hi all,

I have prepared an RFC on server-side request and response objects:

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

This extension provides server-side request and response objects for PHP. These 
are not HTTP message objects proper. They are more like wrappers for existing 
global PHP variables and functions, with some limited additional convenience 
functionality.

This extension defines two classes in the global namespace:

- ServerRequest, composed of read-only copies of PHP superglobals and some 
other commonly-used values, with methods for adding application-specific 
request information in immutable fashion.

- ServerResponse, essentially a wrapper around (and buffer for) 
response-related PHP functions, with some additional convenience methods, and 
self-sending capability.

The extension is available as a PECL package for installation and testing at:

  https://pecl.php.net/package/request

Source and documentation are at:

  https://gitlab.com/pmjones/ext-request

I want to point out that I am not the author of the C code for this extension; 
John Boehr has done the work there, and I appreciate it a great deal.

When I originally raised this topic in September, there were some questions 
left unanswered from Rowan Collins; I'll try to address them below.

* * *

Rowan asked why this would need to be implemented to as an extension or built 
into core: "Does it provide functionality that is hard to implement in a 
userland library?"

It does. Among other things, making public read-only properties is difficult 
and hackish in userland. Making them remain read-only when a parent class is 
extended is (as far as I can tell) impossible. Both of those aspects figure 
prominently in ServerRequest.

* * *

Rowan also asked: "You mention that it is not just an HTTP wrapper, but 
although you mention researching other frameworks, I can't see any reference to 
PSR-7. What do you see as the relationship between your proposal and that 
standardisation effort?"

While PSR-7 is not a framework, I get your point. ;-) For what it's worth, I 
was a sponsor on that proposal, so I'm relatively familiar with its history and 
purpose.

I see the relationship as complementary. Those who want something that matches 
a formal HTTP model more closely can use one of the two popular PSR-7 
implementations, or write their own.  Or they can use `pecl_http`, for that 
matter, which I think PSR-7 ends up mimicking in significant ways.

Those who want something that more closely matches core PHP functionality, or 
the way-of-working presented by many extant frameworks and libraries, might 
find this extension more in line with their needs. I certainly do.

* * *

Finally, Rowan brought this up: "Why is [ServerRequest] property-only, but 
[ServerResponse] method-only? The asymmetry feels awkward to me."

I get why that would be. It's really an outgrowth of the asymmetry that already 
exists in PHP: $_GET, $_POST, et al. are properties representing the request, 
whereas header(), setcookie(), et al. are all functions for sending a response.

Having said that, practical use of ServerRequest the intervening time has given 
rise to some methods for application-related convenience. The methods 
withUrl(), withInput(), and the various withParams() methods allow changing of 
immutable public properties on a clone of ServerRequest.

(As a side note, immutability here is relatively strict. ServerRequest allows 
only null, scalar, and array values in these cases, and recursively checks that 
arrays themselves have only null, scalar, and array values.)

* * *

This (re-)opens the two-week discussion period, though I expect it may go on 
for longer than that.

As this is a language change, a supermajority vote is needed to pass.

Thanks in advance for your questions and criticism.


-- 
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] Re: [RFC] ServerRequest and ServerResponse objects

[Paul Jones]

> On Jan 6, 2017, at 12:51, Pierre Joye  wrote:
> 
> 
> 
> On Jan 5, 2017 3:12 AM, "Paul M. Jones"  wrote:
> 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.
> 
> Same here, not even the initial post. Could you post it again for the record 
> pls?

Can do. In fact, I'll resend the original under a slightly modified subject, 
and we can start the whole thing over. Sorry for the hassle.


-- 
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] Re: [RFC] ServerRequest and ServerResponse objects

[Paul Jones]

Hi Joe,

> On Jan 6, 2017, at 10:56, Joe Watkins  wrote:
> 
> It may be that you need to leave it two weeks from about now, to be on the 
> safe side. I'm sure that's not too different from what you were planning 
> anyway.

I am totally fine with that; I'm not in any particular hurry. :-)


-- 
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] ServerRequest and ServerResponse objects

[Paul Jones]

> On Jan 6, 2017, at 08:34, Adam Baratz  wrote:
> 
> One request: could you update the RFC list[1] so this one is in the "under 
> discussion" section? Makes discovery easier. There's an RFC howto[2] that 
> should cover this.

Thanks for pointing that out. Done!


-- 
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] Re: [RFC] ServerRequest and ServerResponse objects

[Paul Jones]

Hi all,

Today marks two weeks since this RFC was introduced. As I said at the start, 
it's the holidays, so I expect to keep the discussion period open for longer 
than two weeks, but I am surprised at how little discussion there has been.

I find it hard to imagine that all criticisms have been raised, and that the 
remainder of the RFC is otherwise unobjectionable. So, if there are further 
questions, please let me know!


-- 
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][DISCUSSION] - Immutable classes and properties

[Paul Jones]

> On Dec 12, 2016, at 13:36, Andrea Faulds  wrote:
> 
> Consider that some popular applications of immutability ultimately contain a 
> reference to something mutable: PSR-7's immutable HTTP message objects point 
> to mutable streams

Which subverts its overall promise of immutability (and the streams are not the 
only place where the promise of immutability is subverted).


-- 
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] Immutability RFC

[Paul Jones]

> On Nov 19, 2016, at 13:22, Michał Brzuchalski  
> wrote:
> 
> In Event Sourced application Aggregates and Entities are mutable but
> pushing Events for later write but speaking of ValueObject which ideally
> could be immutable classes there is must on immutability and AFAIK there is
> no need for identity for them.

Sure; a Value Object probably needs to be Immutable. But: an Immutable need not 
be a Value Object.

As such, it sounds to me like your concerns in this thread apply to Value 
Objects, not Immutables per se.


-- 
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] Immutability RFC

[Paul Jones]

> On Nov 16, 2016, at 07:57, Silvio Marijić  wrote:
> 
> Hi,
> 
> To anyone who is interested in this RFC. What do you think what behavour we
> should have when you try to compare two immutable objects by identity like
> this:

I don't mean to be overly-nitpicky here, but it strikes me that the issue might 
not be "immutable object" so much as "value object."

That is, an immutable object (or at least a read-only object) might very well 
have an identity.  But a *value* object, in addition to read-only or immutable, 
would have no identity proper.

Maybe using the alternative term (if it applies) would help to clarify the 
situation.


-- 
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] Server-Side Request/Response Objects

[Paul Jones]

Hi all,

First, I want to reiterate that my initial desire was to submit this to PECL, 
to give the project some exercise before bringing it to internals. If someone 
here can nudge the PECL folks about my account request, that'd be appreciated. 
Otherwise, I'm happy to continue the discussion here.

Now, on to the questions and criticisms.

* * *

> On Sep 26, 2016, at 16:10, Korvin Szanto  wrote:
> 
> Personally I would prefer complete HTTP message objects similar to existing 
> PSR-7 implementations be added perhaps alongside these simple classes you've 
> proposed.

Mike Wallner notes his pecl_http work, which I think is good for complete HTTP 
messages.

* * *

> On Sep 26, 2016, at 16:32, Rowan Collins  wrote:
> 
> This sounds like an interesting project, but I have a few questions.
> 
> First, the obvious one: why does this need to be an extension and/or built 
> into core? Are there reasons such as performance for implementing this in C 
> rather than PHP? Does it provide functionality that is hard to implement in a 
> userland library?

The part that's hard to do in userland is public read-only properties that 
cannot be subverted by child classes.  As to building it into core, I think 
it'd probably be better in PECL first, but my application there has been 
ignored so far (though maybe I've not waited long enough).


> You mention that it is not just an HTTP wrapper, but although you mention 
> researching other frameworks, I can't see any reference to PSR-7 
> [http://www.php-fig.org/psr/psr-7/]. What do you see as the relationship 
> between your proposal and that standardisation effort?

I did use it as a research subject, but I failed to include it in my notes; I 
will add it.

I was a sponsor on PSR-7, and I've worked with implementations since before the 
PSR was finalized. I put together the Relay middleware dispatcher, and some 
middleware pieces, and some applications, all using PSR-7, so I'm relatively 
familiar with its ins and outs.

However, I have come to think of it as "not having lived up to its promise." 
That's not to denigrate MWOP, its lead author, whom I encouraged throughout the 
PSR process. But the PSR-7 claim of "immutability" turns out to be only partly 
true; instead, it is quasi-immutable, and so it has the problems that come with 
both mutability and immutability. There are some other problems, which if you 
press me on I'll go into, but not eagerly and only with trepidation.

This work steps back a little bit, to survey the actual implementations of 
server-side requests and responses in userland, and bring together their 
similarities (with a very little bit of refinement), instead of building an 
entirely new and not-thoroughly-examined way of doing things.


> Regarding the design of the objects themselves, why is stdRequest 
> property-only, but stdResponse method-only? The asymmetry feels awkward to me.

Yeah, I get that. They use PHP itself as the example, where the superglobals 
carry all the request-related information, and global functions handle all the 
response-related activity. Part of the idea is to make using StdRequest and 
StdResponse "feel" a bit more like using the superglobals and global functions, 
while still corralling the related information into its own space inside an 
object.


* * *

> 
> On Sep 26, 2016, at 16:45, Michael Wallner  wrote:
> 
> Did you include pecl/http in your research?

I did, but I failed to note it. I will do so.


> It looks like it covers most of that already, if not all.
> I know you said *not* HTTP messages per se, but I don’t see a lot of a 
> difference.

One difference regarding StdRequest is that everything is exposed as read-only 
public properties. All of the frameworks/libraries I looked at had equivalents 
of this:

$value = $request->getPost($key, $default_value);

That's to provide a default value if a particular $_POST key is not available.  
However, under PHP 7, the ?? operator makes that kind of method unnecessary:

$value = $request->post[$key] ?? $default_value;

Further, StdRequest includes things that are not part of HTTP messages (e.g. 
all $_ENV values, and some $_SERVER values).

The main difference regarding StdResponse is that instead of attempting to 
mimic an HTTP Message model, it mimics PHP functionality, except buffering the 
calls instead of sending them right away. (There are some added convenience 
methods as well, drawn from the research subjects.)


* * *

> On Sep 26, 2016, at 16:52, Davey Shafik  wrote:
> 
> Additionally to this, we need to start thinking about what it means to move
> away from simple request/response architectures. In the age of WebSockets
> and HTTP/2 multiplexing w/Server Push, the likelihood of multiple responses
> for one request, or even responses with no associated request, are possible.

I've spoken with Davey, and the summary seems to be that server-push is 
possible, though in an impoverished way, via Link headers. Those can be added 
with header

[PHP-DEV] Server-Side Request/Response Objects

[Paul Jones]

Hi all,

tl;dr: Gauging interest in an extension for server-side PHP request and 
response objects (*not* HTTP messages per se; see below) prior to writing an 
RFC for them on the wiki.

* * *

From time to time we've all heard the complaint that PHP has no built-in 
request object to represent the execution environment. Userland ends up writing 
these themselves, and those are usually tied to a specific library collection 
or framework. The same is true for a response object, to handle the output 
going back to the web client. I've written them myself more than once, as have 
others here.

After doing some library and framework research (linked later) it looks like 
there is a reasonably  common subset of request/response functionality across 
all the userland implementations. That functionality also appears useful to 
non-framework users.

I wrote up a userland implementation for that limited subset of functionality, 
and John Boehr then used that as a reference point for the C version. It is PHP 
7.x only, and you can see the result at:

  

(The userland reference implementation is at 
, and the research 
subjects are in 
.)

The extension provides server-side request and response objects for PHP. They 
are *not* HTTP message objects proper. They are more like wrappers for existing 
global PHP variables and functions, with some limited additional convenience 
functionality. There are only two classes:

- StdRequest, essentially a read-only struct composed of PHP superglobals and 
some other commonly-used values

- StdResponse, essentially a wrapper around (and buffer for) response-related 
PHP functions, with some additional convenience methods, and self-sending 
capability

I thought this might best be offered as a PECL extension first, leading (I 
would hope) to becoming a part of the PHP distribution later if it proves out.  
However, PECL has not responded in the past few days (perhaps I have not waited 
long enough).

In the mean time, I am bringing it up here to either (1) get PECL's attention, 
or (2) begin the RFC process if there's enough interest per 
.

I'm happy to answer any questions, and undergo any criticism, that you may have 
regarding this. Thanks for your time and attention.


-- 

Paul M. Jones
http://paul-m-jones.com


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

Re: [PHP-DEV] Fixing halfway implemented session management - timestamp based session management OR remove session_regenerate_id()

[Paul Jones]

> On Sep 25, 2016, at 16:40, Thomas Bley  wrote:
> 
> why not have a new session module? those who want no change for existing 
> applications keep the old one, new projects can use the new one, those who 
> want more security port their code to the new one. e.g. use session2_start(), 
> etc.

If that's going to be the approach (and I find it appealing) then perhaps there 
should be other things accomplished as part of the new work; e.g., disable the 
automatic sending of cookie headers and make it explicit. Or wrap all the 
features in objects. (I don't want to volunteer anyone else for more work, 
though, and I myself am not competent to implement those ideas.)


-- 

Paul M. Jones
http://paul-m-jones.com




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

Re: [PHP-DEV] [RFC] Pipe Operator

[Paul Jones]

> On Apr 29, 2016, at 14:58, Sara Golemon  wrote:
> 
> This is one of my favorites out of HackLang.  It's pure syntactic
> sugar, but it goes a long way towards improving readability.
> https://wiki.php.net/rfc/pipe-operator

I like this a lot.


-- 

Paul M. Jones
http://paul-m-jones.com




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

Re: [PHP-DEV] [RFC] Square bracket syntax for array destructuring assignment

[Paul Jones]

> On Apr 7, 2016, at 07:21, Andrea Faulds  wrote:
> 
> Hi everyone,
> 
> Bob and I have made an RFC which proposes an alternative syntax for list():
> 
> https://wiki.php.net/rfc/short_list_syntax
> 
> Please tell us your thoughts.

Reading the name of the RFC led me to imagine what I thought it might be, and 
lo, it was!

So, yes, I like it.


-- 

Paul M. Jones
http://paul-m-jones.com





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

[PHP-DEV] CVS Account Request: pmjones

[Paul Jones]

Access to the PEAR module to maintain File_IMC and other packages

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