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

[Chris Riley]

On Sat, 15 Aug 2020 at 10:54, Michał Marcin Brzuchalski <
michal.brzuchal...@gmail.com> wrote:

> Hi Theodore,
>
> pt., 14 sie 2020, 22:16 użytkownik Theodore Brown 
> napisał:
>
> > On Fri, Aug 14, 2020 at 2:23 PM Derick Rethans  wrote:
> >
> > > On Fri, 14 Aug 2020, Sara Golemon wrote:
> > >
> > > > > Derick and Benjamin (and Sara), are these requests reasonable? If
> > > > > the RFC follows the discussion period rule and contains all the
> > > > > relevant information, I will be much more confident that it is
> > > > > resulting in the best long term outcome (and I think this would
> > > > > speak for many others on list as well).
> > > >
> > > > Honestly, the current end date is fine, because the intent of the
> rule
> > > > is met.  However, I do like that you're seeking a solution which
> helps
> > > > to put concerns to rest.
> > > >
> > > > The only part which irks me is that we have 50-some votes already
> cast
> > > > that would be thrown out and have to be redone, and that's on what is
> > > > already the 3rd vote on this syntax.
> > > >
> > > > I'm vote fatigued, personally.  However, we're going to have to live
> > > > with this syntax forever once it's out, so we should believe that we
> > > > believe in it.
> > >
> > > As I've said, I have no problems with *extending* the time by the week
> > > and a bit that I missed. I disagree about having to stop, wipe, and
> > > revote. As you said, vote fatigue.
> >
> > Hi Derick and Sara,
> >
> > I don't think it's reasonable to simply extend the period, when the
> > RFC has been significantly updated to include important details that
> > were missing when most people cast their vote. Otherwise the vote
> > result does not reflect the contents of the RFC, and therefore cannot
> > be considered valid.
> >
> > If vote fatigue is really the most important consideration here,
> > would this RFC have been brought to vote in the first place?
> >
>
> I don't think there's anything significant changed in the RFC. I really
> doubt the vote result will change significantly.
>
> Currently you're the only one who wants to wipe the vote and there is no
> much voices willing to follow your proposal.
>
> Personally I think extending the vote by additional week is fair enough.
>
> Cheers,
> Michał Marcin Brzuchalski
>
> >
>

On the BC breaks front, I actually ended up using @[] in some code
yesterday and PHP Storm already (incorrectly) flagged it as an error.
[image: image.png]
So maybe, inadvertently, not as bad as we think it is?

~C

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

[Chris Riley]

On Tue, 11 Aug 2020 at 13:21, Derick Rethans  wrote:

> On Tue, 11 Aug 2020, Chris Riley wrote:
>
> > Quick question.
> >
> > What is the expected behaviour of:
> >
> > @[Bar()];
> > class Foo {}
>
> That will error out in PHP 8, with:
>
> Parse error: syntax error, unexpected token ";" in Standard input code on
> line 2
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>

Is



on it's own an error?

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

[Chris Riley]

On Tue, 11 Aug 2020 at 12:40, Matteo Beccati  wrote:

> Hi,
>
> On 11/08/2020 12:10, Chris Riley wrote:
> > What is the expected behaviour of:
> >
> > @[Bar()];
> > class Foo {}
> >
> > That would appear to be valid code and for the difference of a single ;
> > does wildly different things, assuming there is a function Bar defined
> > somewhere. (and only by the fact that @ doesn't suppress fatal errors
> does
> > it not cause utter confusion if Bar isn't defined)
> I think an 'unexpected token ";"', which is what currently happens if
> you do the same with "@@" on current master, would still be an
> appropriate behaviour.
>
> FWIW, I haven't made up my mind yet and that's why I haven't cast my
> vote yet.
>
> I do agree with Chris here and I somehow mentally parse the above as
> "silencing an array containing a function call", which to me is bad
> enough to rule the syntax out. I would surely get used to it, if
> accepted, but that's how I feel now.
>
> Rust's #[] to me looks better, but I am still bothered by the fact that
> it can be used in a backwards compatible way, but not fully so
> (multi-line, syntax errors).
>
> And "@@" is super ugly, although I'm not bothered that much by its lack
> of ending delimiter, since most of the times longer attributes will
> still, albeit just visually, have some in the closing ")".
>
>
> Cheers
> --
> Matteo Beccati
>
> Development & Consulting - http://www.beccati.com/


My concern wasn't so much of mentally parsing it as a silenced function
call in an array; more that PHP currently parses it that way. That example
becoming invalid code would be a reasonable option, but leaving it as valid
code just sets people up to spend ages hunting a "why is this annotation
not being applied to my class bug". (and before anyone says this won't
happen; I have spent hours in the past tracking down missing annotations
which occured because of the difference between /* and /**)

For the record, my preference is @[ ], I just also like removing as many
potential cases of debugging stupid issues as possible.

~C

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

[Chris Riley]

Hi,

Quick question.

What is the expected behaviour of:

@[Bar()];
class Foo {}

That would appear to be valid code and for the difference of a single ;
does wildly different things, assuming there is a function Bar defined
somewhere. (and only by the fact that @ doesn't suppress fatal errors does
it not cause utter confusion if Bar isn't defined)

Regards,
Chris

On Mon, 10 Aug 2020 at 09:41, Derick Rethans  wrote:

> Hi,
>
> I've just opened the vote to make sure we don't make a terrible mistake
> with using the @@ syntax for attributes:
>
> https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
>
> The first vote is a vote to say that you have an opinion about attribute
> syntax. Make sure to read up on the discussion on the mailinglist if you
> haven't done so yet.
>
> The second vote is an STV vote.
>
> In STV you SHOULD rank *all* choices, but don't pick the same one more
> than once, as that will invalidate your vote.
>
> Please have a objective look at the table
> (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> don't just go by asthetics.
>
> The vote ends August 23, 24:00 UTC.
>
> cheers,
> Derick
>
> --
> PHP 7.4 Release Manager
> Host of PHP Internals News: https://phpinternals.news
> Like Xdebug? Consider supporting me: https://xdebug.org/support
> https://derickrethans.nl | https://xdebug.org | https://dram.io
> twitter: @derickr and @xdebug
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[Chris Riley]

Hi all,

RFC link: https://wiki.php.net/rfc/renamed_parameters

I have spent the weekend working on a final revision for this RFC to
address several of the points brought up. Specifically:

- Cut down the scope of the RFC to only focus on delivering an opt in to
named parameters, with the renaming ability explicitly pushed into future
scope as opposed to leaving it to the RM discretion. This will allow a
fuller discussion on how best to support renaming going forward, be it
using my proposed syntax or using attributes.
- Focused in on the technical issues as opposed to subjective arguments
for/against.
- Added additional example of the polymorphism problem when it comes to the
behaviour of variadics, which didn't seem to come up in the original RFC.
- Added resolution on dealing with the PHP standard library, as this is an
enhancement to the original named parameters RFC, this RFC proposes to opt
in the PHP standard library. There are a couple of minor changes to
behaviour for classes which extend built ins to make upgrading smoother.
- Clarified changes to reflection parameter
- Added alternative implementation option using attributes which will be
the subject of an additional voting option for those who would prefer to go
down this route.

I think the RFC now represents a concrete problem and solution suitable for
voting on, but I'm going to leave discussion open for a few days in case
anyone has any queries on the revisions.

Regards,
Chris


On Fri, 24 Jul 2020 at 12:12, Chris Riley  wrote:

> Hi all,
>
> The named parameters RFC has been accepted, despite significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter names part of the API; a change to them would cause a BC break
> for any library users who decide to use the new feature.
>
> It is likely that the way this will shake out is that some maintainers
> will accept the additional overhead of including parameter names in their
> BC guidelines and others will not, this leaves users unsure if they can use
> the new feature without storing up issues in potentially minor/security
> releases of the libraries they use. This is not really an ideal situation.
>
> More pressing a point is that the current implementation breaks object
> polymorphism. Consider this example (simplified from one of my codebases)
>
> interface Handler {
> public function handle($message);
> }
>
> class RegistrationHandler implements Handler {
> public function handle($registraionCommand);
> }
>
> class ForgottenPasswordHandler implements Handler {
> public function handle($forgottenPasswordCommand);
> }
>
> class MessageBus {
> //...
> public function addHandler(string $message, Handler $handler) { //... }
> public function getHandler(string $messageType): Handler { //... }
> public function dispatch($message)
> {
> $this->getHandler(get_class($message))->handle(message: $message);
> }
> }
>
> This code breaks at run time.
>
> Proposals were made for resolutions to this issue however all of them
> require trade offs and could potentially break existing code.
>
> My proposal to resolve these two issues is to add the ability to rename
> parameters with a new syntax as follows.
>
> function callBar(Foo $internalName:externalName) {
> $internalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> This allows both the above problems to be resolved, by renaming the
> internal parameter and keeping the external signature the same.
>
> I propose that the RFC would have two voting options.
>
> The first would be to implement it as proposed above, this would allow any
> parameter to be called by name regardless of the intentions of the author
> of the method/function and is closest to the current behaviour.
>
> The second option would be to use this syntax to make named parameters in
> userland code explicitly opt in. As such an additional shortcut syntax
> would be implemented: $: to designate a named parameter. eg
>
> function callBar($:externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x); // Error: cannot call parameter $externalName
> by name.
>
> There are pros and cons to this second approach, on the one hand it
> reduces the usefulness of the named parameter syntax by requiring changes
> to old code to enable it (although this could probably be automated fairly
> easily) however it does provide

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[Chris Riley]

Hi all,

Thanks for the feedback so far. In light of the feedback received both here
and privately, I've made 3 changes to the RFC document:

1. The original option 1, allowing renaming parameters but not requiring an
explicit opt in to enable them to be called by name has been dropped. The
proposal is now only for explicit opt in parameters with renaming as a
possibility. The reasoning for this, is that although I included option 1
as I thought it might be more likely to be accepted; many people pointed
out that we are very close to the cutoff date for PHP 8.0 and that
implementing such a change would likely be too big to get done in time.
Option 1 would be possible to include in PHP 8.1 as it doesn't break BC,
this means that the proposal can be brought back targeting 8.1 should
option 2 not be accepted.

2. With respect to the feature freeze date, I've added a possible strategy
to deal with a staged implementation, should the release managers not feel
comfortable including the full feature at this late stage.

3. I have documented the main objections to the RFC on the RFC itself and
included my rebuttals; should anyone feel I've not represented their point
fairly let me know and I'll update.

Regards,
Chris

On Fri, 24 Jul 2020 at 12:12, Chris Riley  wrote:

> Hi all,
>
> The named parameters RFC has been accepted, despite significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter names part of the API; a change to them would cause a BC break
> for any library users who decide to use the new feature.
>
> It is likely that the way this will shake out is that some maintainers
> will accept the additional overhead of including parameter names in their
> BC guidelines and others will not, this leaves users unsure if they can use
> the new feature without storing up issues in potentially minor/security
> releases of the libraries they use. This is not really an ideal situation.
>
> More pressing a point is that the current implementation breaks object
> polymorphism. Consider this example (simplified from one of my codebases)
>
> interface Handler {
> public function handle($message);
> }
>
> class RegistrationHandler implements Handler {
> public function handle($registraionCommand);
> }
>
> class ForgottenPasswordHandler implements Handler {
> public function handle($forgottenPasswordCommand);
> }
>
> class MessageBus {
> //...
> public function addHandler(string $message, Handler $handler) { //... }
> public function getHandler(string $messageType): Handler { //... }
> public function dispatch($message)
> {
> $this->getHandler(get_class($message))->handle(message: $message);
> }
> }
>
> This code breaks at run time.
>
> Proposals were made for resolutions to this issue however all of them
> require trade offs and could potentially break existing code.
>
> My proposal to resolve these two issues is to add the ability to rename
> parameters with a new syntax as follows.
>
> function callBar(Foo $internalName:externalName) {
> $internalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> This allows both the above problems to be resolved, by renaming the
> internal parameter and keeping the external signature the same.
>
> I propose that the RFC would have two voting options.
>
> The first would be to implement it as proposed above, this would allow any
> parameter to be called by name regardless of the intentions of the author
> of the method/function and is closest to the current behaviour.
>
> The second option would be to use this syntax to make named parameters in
> userland code explicitly opt in. As such an additional shortcut syntax
> would be implemented: $: to designate a named parameter. eg
>
> function callBar($:externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x); // Error: cannot call parameter $externalName
> by name.
>
> There are pros and cons to this second approach, on the one hand it
> reduces the usefulness of the named parameter syntax by requiring changes
> to old code to enable it (although this could probably be automated fairly
> easily) however it does provide a neater solution to the second problem in
> that, to prevent the runtime errors in the second issue example, every
> child class would need to use the rename syntax on it's parameter to
> prevent errors, whereas if we went do

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Chris Riley]

On Fri, 24 Jul 2020 at 16:41, Sara Golemon  wrote:

> On Fri, Jul 24, 2020 at 10:10 AM Nikita Popov 
> wrote:
> > > > You added PHP 8.0 as a proposed version, but that will not be
> possible
> > > > anymore 2 weeks of discussion + 2 weeks of voting are not possible
> to fit
> > > > in before the feature freeze, which is in 11 days.
> > >
> > > While you are technically correct, the primary point of a feature
> freeze
> > > is not allowing in completely new features.
> > > It will always happen that there are changes and extensions to RFCs
> > > introduced for the next version which may need to be addressed first,
> > > because there is massive benefit to the new feature in that case.
> (from a
> > > backwards/forwards compatibility standpoint for example)
> > >
> > We should of course be open to making minor adjustments due to
> > unanticipated issues after feature freeze -- after all, that's where we
> > gain experience with new features. The emphasis here is very much on
> > *minor* and *unanticipated* though.
> >
>
> Endorsing this.  Anything post FF needs to be held to a high standard.
> Minor and Unanticipated changes.
> * The option to set alt-names on parameters is substantial.
>  * Making named params explicitly opt-in is less substantial (though
> certainly not trivial), especially if it were hung off an attribute which
> would mean no actual new syntax, but Niki's point that it wasn't an unknown
> or unanticipated issue stands.
>
> I share OP's worry that this pushes workload onto library and framework
> maintainers, and I wouldn't look forward to the review of all APIs to make
> sure their names are correct, but the vote has spoken.  We should
> absolutely continue pursuing this topic with an eye to 8.1 so that library
> updates are less painful moving forward.
>
> -Sara
>

Hi,

My main concern with named params as they currently stand is that they are
fully enabled: if we release PHP 8.0 with named params as they are now,
there's no take backsies. Fixing the polymorphism issue and the maintenance
issues become much harder as you have to work around the fact that there
will be userland code relying on the feature as shipped. If we target
fixing this in 8.1 we would lose the option of being able to make named
params explicitly opt in and as such any possibility of a strict solution
to the polymorphism issues that it throws up.

Regards,
Chris

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

[Chris Riley]

Hi all,

Following up from this I've created a draft RFC:
https://wiki.php.net/rfc/renamed_parameters will move to in discussion once
I've ensured everything important has been captured.

Regards,
Chris

On Fri, 24 Jul 2020 at 12:12, Chris Riley  wrote:

> Hi all,
>
> The named parameters RFC has been accepted, despite significant objections
> from maintainers of larger OSS projects due to the overhead it adds to
> maintaining backwards compatibility as it has now made method/function
> parameter names part of the API; a change to them would cause a BC break
> for any library users who decide to use the new feature.
>
> It is likely that the way this will shake out is that some maintainers
> will accept the additional overhead of including parameter names in their
> BC guidelines and others will not, this leaves users unsure if they can use
> the new feature without storing up issues in potentially minor/security
> releases of the libraries they use. This is not really an ideal situation.
>
> More pressing a point is that the current implementation breaks object
> polymorphism. Consider this example (simplified from one of my codebases)
>
> interface Handler {
> public function handle($message);
> }
>
> class RegistrationHandler implements Handler {
> public function handle($registraionCommand);
> }
>
> class ForgottenPasswordHandler implements Handler {
> public function handle($forgottenPasswordCommand);
> }
>
> class MessageBus {
> //...
> public function addHandler(string $message, Handler $handler) { //... }
> public function getHandler(string $messageType): Handler { //... }
> public function dispatch($message)
> {
> $this->getHandler(get_class($message))->handle(message: $message);
> }
> }
>
> This code breaks at run time.
>
> Proposals were made for resolutions to this issue however all of them
> require trade offs and could potentially break existing code.
>
> My proposal to resolve these two issues is to add the ability to rename
> parameters with a new syntax as follows.
>
> function callBar(Foo $internalName:externalName) {
> $internalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> This allows both the above problems to be resolved, by renaming the
> internal parameter and keeping the external signature the same.
>
> I propose that the RFC would have two voting options.
>
> The first would be to implement it as proposed above, this would allow any
> parameter to be called by name regardless of the intentions of the author
> of the method/function and is closest to the current behaviour.
>
> The second option would be to use this syntax to make named parameters in
> userland code explicitly opt in. As such an additional shortcut syntax
> would be implemented: $: to designate a named parameter. eg
>
> function callBar($:externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x);
>
> If a parameter is not opted in, a compile time error is raised:
>
> function callBar($externalName) {
> $externalName->bar();
> }
>
> $x = new Foo();
> callBar(externalName: $x); // Error: cannot call parameter $externalName
> by name.
>
> There are pros and cons to this second approach, on the one hand it
> reduces the usefulness of the named parameter syntax by requiring changes
> to old code to enable it (although this could probably be automated fairly
> easily) however it does provide a neater solution to the second problem in
> that, to prevent the runtime errors in the second issue example, every
> child class would need to use the rename syntax on it's parameter to
> prevent errors, whereas if we went down this route, the parent class could
> just not opt into the named parameter syntax and the code would function as
> expected.
>
> Another advantage is that with the ability to rename parameters using the
> opt in, we gain some flexibility to tighten up the LSP rules relating to
> named parameter inheritance.
>
> class Foo {
> public function bar($:param) { //... }
> public function baz($internal:external) { //... }
> }
>
> // OK
> class Bar {
> public function bar($renamed:param) { //... }
> public function baz($renamed:external) { //... }
> }
>
> // Compile time error cannot rename named parameter $:param (renamed to
> $:renamedParam)
> class Baz {
> public function bar($:renamedParam) { //... }
> }
>
> // Compile time error cannot rename named parameter $:external (renamed to
> $:renamed)
> class Baz {
> public function baz($internal:renamed) { //... }
> }
>
> While this would be technically po

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Chris Riley]

On Fri, 24 Jul 2020 at 14:43, Benjamin Eberlei  wrote:

>
>
> On Fri, Jul 24, 2020 at 3:15 PM Chris Riley  wrote:
>
>> On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jul 24, 2020 at 1:13 PM Chris Riley  wrote:
>>>
>>>> Hi all,
>>>>
>>>> The named parameters RFC has been accepted, despite significant
>>>> objections
>>>> from maintainers of larger OSS projects due to the overhead it adds to
>>>> maintaining backwards compatibility as it has now made method/function
>>>> parameter names part of the API; a change to them would cause a BC break
>>>> for any library users who decide to use the new feature.
>>>>
>>>
>>> Hi Chris,
>>>
>>> I had something similar in mind, but using an attribute. Here is a patch
>>> that already allows this:
>>>
>>>
>>> https://github.com/beberlei/php-src/commit/4b0a02f9c6ba579f93ec57c754fa3794a96c696b
>>>
>>> Idea: Have a @@NameAlias attribute, where you can provide a second name
>>> for the attribute. This would allow to refactor parameter names by adding
>>> the attribute with the old name as an alias.
>>>
>>>
>>>>
>>>> It is likely that the way this will shake out is that some maintainers
>>>> will
>>>> accept the additional overhead of including parameter names in their BC
>>>> guidelines and others will not, this leaves users unsure if they can use
>>>> the new feature without storing up issues in potentially minor/security
>>>> releases of the libraries they use. This is not really an ideal
>>>> situation.
>>>>
>>>> More pressing a point is that the current implementation breaks object
>>>> polymorphism. Consider this example (simplified from one of my
>>>> codebases)
>>>>
>>>> interface Handler {
>>>> public function handle($message);
>>>> }
>>>>
>>>> class RegistrationHandler implements Handler {
>>>> public function handle($registraionCommand);
>>>> }
>>>>
>>>> class ForgottenPasswordHandler implements Handler {
>>>> public function handle($forgottenPasswordCommand);
>>>> }
>>>>
>>>> class MessageBus {
>>>> //...
>>>> public function addHandler(string $message, Handler $handler) {
>>>> //... }
>>>> public function getHandler(string $messageType): Handler { //... }
>>>> public function dispatch($message)
>>>> {
>>>> $this->getHandler(get_class($message))->handle(message:
>>>> $message);
>>>> }
>>>> }
>>>>
>>>> This code breaks at run time.
>>>>
>>>> Proposals were made for resolutions to this issue however all of them
>>>> require trade offs and could potentially break existing code.
>>>>
>>>> My proposal to resolve these two issues is to add the ability to rename
>>>> parameters with a new syntax as follows.
>>>>
>>>> function callBar(Foo $internalName:externalName) {
>>>> $internalName->bar();
>>>> }
>>>>
>>>> $x = new Foo();
>>>> callBar(externalName: $x);
>>>>
>>>> This allows both the above problems to be resolved, by renaming the
>>>> internal parameter and keeping the external signature the same.
>>>>
>>>> I propose that the RFC would have two voting options.
>>>>
>>>> The first would be to implement it as proposed above, this would allow
>>>> any
>>>> parameter to be called by name regardless of the intentions of the
>>>> author
>>>> of the method/function and is closest to the current behaviour.
>>>>
>>>> The second option would be to use this syntax to make named parameters
>>>> in
>>>> userland code explicitly opt in. As such an additional shortcut syntax
>>>> would be implemented: $: to designate a named parameter. eg
>>>>
>>>> function callBar($:externalName) {
>>>> $externalName->bar();
>>>> }
>>>>
>>>> $x = new Foo();
>>>> callBar(externalName: $x);
>>>>
>>>> If a parameter is not opted in, a compile time error is raised:
>>>>
>>>> fun

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Chris Riley]

On Fri, 24 Jul 2020 at 14:01, Benjamin Eberlei  wrote:

>
>
> On Fri, Jul 24, 2020 at 1:13 PM Chris Riley  wrote:
>
>> Hi all,
>>
>> The named parameters RFC has been accepted, despite significant objections
>> from maintainers of larger OSS projects due to the overhead it adds to
>> maintaining backwards compatibility as it has now made method/function
>> parameter names part of the API; a change to them would cause a BC break
>> for any library users who decide to use the new feature.
>>
>
> Hi Chris,
>
> I had something similar in mind, but using an attribute. Here is a patch
> that already allows this:
>
>
> https://github.com/beberlei/php-src/commit/4b0a02f9c6ba579f93ec57c754fa3794a96c696b
>
> Idea: Have a @@NameAlias attribute, where you can provide a second name
> for the attribute. This would allow to refactor parameter names by adding
> the attribute with the old name as an alias.
>
>
>>
>> It is likely that the way this will shake out is that some maintainers
>> will
>> accept the additional overhead of including parameter names in their BC
>> guidelines and others will not, this leaves users unsure if they can use
>> the new feature without storing up issues in potentially minor/security
>> releases of the libraries they use. This is not really an ideal situation.
>>
>> More pressing a point is that the current implementation breaks object
>> polymorphism. Consider this example (simplified from one of my codebases)
>>
>> interface Handler {
>> public function handle($message);
>> }
>>
>> class RegistrationHandler implements Handler {
>> public function handle($registraionCommand);
>> }
>>
>> class ForgottenPasswordHandler implements Handler {
>> public function handle($forgottenPasswordCommand);
>> }
>>
>> class MessageBus {
>> //...
>> public function addHandler(string $message, Handler $handler) { //...
>> }
>> public function getHandler(string $messageType): Handler { //... }
>> public function dispatch($message)
>> {
>> $this->getHandler(get_class($message))->handle(message: $message);
>> }
>> }
>>
>> This code breaks at run time.
>>
>> Proposals were made for resolutions to this issue however all of them
>> require trade offs and could potentially break existing code.
>>
>> My proposal to resolve these two issues is to add the ability to rename
>> parameters with a new syntax as follows.
>>
>> function callBar(Foo $internalName:externalName) {
>> $internalName->bar();
>> }
>>
>> $x = new Foo();
>> callBar(externalName: $x);
>>
>> This allows both the above problems to be resolved, by renaming the
>> internal parameter and keeping the external signature the same.
>>
>> I propose that the RFC would have two voting options.
>>
>> The first would be to implement it as proposed above, this would allow any
>> parameter to be called by name regardless of the intentions of the author
>> of the method/function and is closest to the current behaviour.
>>
>> The second option would be to use this syntax to make named parameters in
>> userland code explicitly opt in. As such an additional shortcut syntax
>> would be implemented: $: to designate a named parameter. eg
>>
>> function callBar($:externalName) {
>> $externalName->bar();
>> }
>>
>> $x = new Foo();
>> callBar(externalName: $x);
>>
>> If a parameter is not opted in, a compile time error is raised:
>>
>> function callBar($externalName) {
>> $externalName->bar();
>> }
>>
>> $x = new Foo();
>> callBar(externalName: $x); // Error: cannot call parameter $externalName
>> by
>> name.
>>
>> There are pros and cons to this second approach, on the one hand it
>> reduces
>> the usefulness of the named parameter syntax by requiring changes to old
>> code to enable it (although this could probably be automated fairly
>> easily)
>> however it does provide a neater solution to the second problem in that,
>> to
>> prevent the runtime errors in the second issue example, every child class
>> would need to use the rename syntax on it's parameter to prevent errors,
>> whereas if we went down this route, the parent class could just not opt
>> into the named parameter syntax and the code would function as expected.
>>
>> Another advantage is that with the ability to rename parameters using the
>> opt in, we gain some flexibility to tighten

[PHP-DEV] Wiki Karma request

[Chris Riley]

Hi,

Requesting karma to create RFC's for my account: carnage. Want to get the
ball rolling on https://externals.io/message/61

Thanks,
Chris

Re: [PHP-DEV] [RFC][Proposal] Renamed parameters

[Chris Riley]

On Fri, 24 Jul 2020 at 13:05, Marcio Almada  wrote:

> Hi
>
> >
> > Hi all,
> >
> > The named parameters RFC has been accepted, despite significant
> objections
> > from maintainers of larger OSS projects due to the overhead it adds to
> > maintaining backwards compatibility as it has now made method/function
> > parameter names part of the API; a change to them would cause a BC break
> > for any library users who decide to use the new feature.
> >
> > It is likely that the way this will shake out is that some maintainers
> will
> > accept the additional overhead of including parameter names in their BC
> > guidelines and others will not, this leaves users unsure if they can use
> > the new feature without storing up issues in potentially minor/security
> > releases of the libraries they use. This is not really an ideal
> situation.
> >
> > More pressing a point is that the current implementation breaks object
> > polymorphism. Consider this example (simplified from one of my codebases)
> >
> > interface Handler {
> > public function handle($message);
> > }
> >
> > class RegistrationHandler implements Handler {
> > public function handle($registraionCommand);
> > }
> >
> > class ForgottenPasswordHandler implements Handler {
> > public function handle($forgottenPasswordCommand);
> > }
> >
> > class MessageBus {
> > //...
> > public function addHandler(string $message, Handler $handler) {
> //... }
> > public function getHandler(string $messageType): Handler { //... }
> > public function dispatch($message)
> > {
> > $this->getHandler(get_class($message))->handle(message:
> $message);
> > }
> > }
> >
> > This code breaks at run time.
> >
> > Proposals were made for resolutions to this issue however all of them
> > require trade offs and could potentially break existing code.
> >
> > My proposal to resolve these two issues is to add the ability to rename
> > parameters with a new syntax as follows.
> >
> > function callBar(Foo $internalName:externalName) {
> > $internalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > This allows both the above problems to be resolved, by renaming the
> > internal parameter and keeping the external signature the same.
> >
> > I propose that the RFC would have two voting options.
> >
> > The first would be to implement it as proposed above, this would allow
> any
> > parameter to be called by name regardless of the intentions of the author
> > of the method/function and is closest to the current behaviour.
> >
> > The second option would be to use this syntax to make named parameters in
> > userland code explicitly opt in. As such an additional shortcut syntax
> > would be implemented: $: to designate a named parameter. eg
> >
> > function callBar($:externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > If a parameter is not opted in, a compile time error is raised:
> >
> > function callBar($externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x); // Error: cannot call parameter $externalName
> by
> > name.
> >
> > There are pros and cons to this second approach, on the one hand it
> reduces
> > the usefulness of the named parameter syntax by requiring changes to old
> > code to enable it (although this could probably be automated fairly
> easily)
> > however it does provide a neater solution to the second problem in that,
> to
> > prevent the runtime errors in the second issue example, every child class
> > would need to use the rename syntax on it's parameter to prevent errors,
> > whereas if we went down this route, the parent class could just not opt
> > into the named parameter syntax and the code would function as expected.
> >
> > Another advantage is that with the ability to rename parameters using the
> > opt in, we gain some flexibility to tighten up the LSP rules relating to
> > named parameter inheritance.
> >
> > class Foo {
> > public function bar($:param) { //... }
> > public function baz($internal:external) { //... }
> > }
> >
> > // OK
> > class Bar {
> > public function bar($renamed:param) { //... }
> > public function baz($renamed:external) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:param (renamed to
> > $:renamedParam)
> > class Baz {
> > public function bar($:renamedParam) { //... }
> > }
> >
> > // Compile time error cannot rename named parameter $:external (renamed
> to
> > $:renamed)
> > class Baz {
> > public function baz($internal:renamed) { //... }
> > }
> >
> > While this would be technically possible with the first option (no opt
> in)
> > it would break any existing code which renames a parameter as every
> > parameter would be subject to these rules.
> >
> > I don't have Wiki karma so can't post this yet; but I want to get the
> ball
> > rolling on discussion as feature freeze is coming up fast and if 

[PHP-DEV] [RFC][Proposal] Renamed parameters

[Chris Riley]

Hi all,

The named parameters RFC has been accepted, despite significant objections
from maintainers of larger OSS projects due to the overhead it adds to
maintaining backwards compatibility as it has now made method/function
parameter names part of the API; a change to them would cause a BC break
for any library users who decide to use the new feature.

It is likely that the way this will shake out is that some maintainers will
accept the additional overhead of including parameter names in their BC
guidelines and others will not, this leaves users unsure if they can use
the new feature without storing up issues in potentially minor/security
releases of the libraries they use. This is not really an ideal situation.

More pressing a point is that the current implementation breaks object
polymorphism. Consider this example (simplified from one of my codebases)

interface Handler {
public function handle($message);
}

class RegistrationHandler implements Handler {
public function handle($registraionCommand);
}

class ForgottenPasswordHandler implements Handler {
public function handle($forgottenPasswordCommand);
}

class MessageBus {
//...
public function addHandler(string $message, Handler $handler) { //... }
public function getHandler(string $messageType): Handler { //... }
public function dispatch($message)
{
$this->getHandler(get_class($message))->handle(message: $message);
}
}

This code breaks at run time.

Proposals were made for resolutions to this issue however all of them
require trade offs and could potentially break existing code.

My proposal to resolve these two issues is to add the ability to rename
parameters with a new syntax as follows.

function callBar(Foo $internalName:externalName) {
$internalName->bar();
}

$x = new Foo();
callBar(externalName: $x);

This allows both the above problems to be resolved, by renaming the
internal parameter and keeping the external signature the same.

I propose that the RFC would have two voting options.

The first would be to implement it as proposed above, this would allow any
parameter to be called by name regardless of the intentions of the author
of the method/function and is closest to the current behaviour.

The second option would be to use this syntax to make named parameters in
userland code explicitly opt in. As such an additional shortcut syntax
would be implemented: $: to designate a named parameter. eg

function callBar($:externalName) {
$externalName->bar();
}

$x = new Foo();
callBar(externalName: $x);

If a parameter is not opted in, a compile time error is raised:

function callBar($externalName) {
$externalName->bar();
}

$x = new Foo();
callBar(externalName: $x); // Error: cannot call parameter $externalName by
name.

There are pros and cons to this second approach, on the one hand it reduces
the usefulness of the named parameter syntax by requiring changes to old
code to enable it (although this could probably be automated fairly easily)
however it does provide a neater solution to the second problem in that, to
prevent the runtime errors in the second issue example, every child class
would need to use the rename syntax on it's parameter to prevent errors,
whereas if we went down this route, the parent class could just not opt
into the named parameter syntax and the code would function as expected.

Another advantage is that with the ability to rename parameters using the
opt in, we gain some flexibility to tighten up the LSP rules relating to
named parameter inheritance.

class Foo {
public function bar($:param) { //... }
public function baz($internal:external) { //... }
}

// OK
class Bar {
public function bar($renamed:param) { //... }
public function baz($renamed:external) { //... }
}

// Compile time error cannot rename named parameter $:param (renamed to
$:renamedParam)
class Baz {
public function bar($:renamedParam) { //... }
}

// Compile time error cannot rename named parameter $:external (renamed to
$:renamed)
class Baz {
public function baz($internal:renamed) { //... }
}

While this would be technically possible with the first option (no opt in)
it would break any existing code which renames a parameter as every
parameter would be subject to these rules.

I don't have Wiki karma so can't post this yet; but I want to get the ball
rolling on discussion as feature freeze is coming up fast and if we want to
go for the second option, that must hit before the named parameter syntax
is in a tagged version of PHP.

Regards,
Chris

Re: [PHP-DEV][RFC] Cast in foreach

[Chris Riley]

Cast would work for both key and value, although I think the instances
where you need to cast a key will be fewer.

On Thu, Feb 21, 2019, 15:08 Legale.legale  wrote:

> what about:
>
> foreach($array as $i=>$v) {}
>
> ?On Feb 21, 2019 13:15, Chris Riley  wrote:
> >
> > Hi internals,
> >
> > I'd like to propose opening an rfc to make the following syntax legal:
> >
> > foreach($array as (int) $i) {}
> >
> > Which would be functionally equivalent to
> >
> > foreach($array as $i) {
> > $i=(int) $i;
> > }
> >
> > Thoughts? Feedback?
> > ~C
>

Re: [PHP-DEV][RFC] Cast in foreach

[Chris Riley]

In this instance, I would expect the cast to come before each variable
eg foreach ($data as ["id" => (int) $id, "name" => (string) $name])

On Thu, Feb 21, 2019, 13:28 Kalle Sommer Nielsen  wrote:

> Den tor. 21. feb. 2019 kl. 14.16 skrev Chris Riley :
> >
> > Hi internals,
> >
> > I'd like to propose opening an rfc to make the following syntax legal:
> >
> > foreach($array as (int) $i) {}
>
> How would this interact with the foreach-list syntax?
>
> $data = [
> ["id" => 1, "name" => 'Tom'],
> ["id" => 2, "name" => 'Fred'],
> ];
>
> foreach ($data as ["id" => $id, "name" => $name]) {
> echo "id: $id, name: $name\n";
> }
>
> Having something like:
> foreach ($data as (int) ["id" => $id, "name" => $name]) {
>
> Would then make both $id and $name integers?
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>

[PHP-DEV][RFC] Cast in foreach

[Chris Riley]

Hi internals,

I'd like to propose opening an rfc to make the following syntax legal:

foreach($array as (int) $i) {}

Which would be functionally equivalent to

foreach($array as $i) {
$i=(int) $i;
}

Thoughts? Feedback?
~C

Re: [PHP-DEV] [RFC] [DISCUSSION] Scalar Pseudo-type

[Chris Riley]

Hi,

How useful is "scalar" as a type hint? I'm not sure it provides any benefit
over "mixed".

Would it not be better to copy Hack and instead introduce two type hints:
"num" (or "number") which is int|float and "arraykey" which is string|int?

To me, these are much more useful pseudo types than "scalar" which gives me
no usable guarantees over the type of data a function/method is receiving.

~C

On Tue, 2 Jan 2018 at 08:38 Tony Marston  wrote:

> "Lester Caine"  wrote in message
> news:a1bb2452-3969-ca72-cf19-4ca4bcd90...@lsces.co.uk...
> >
> >On 31/12/17 22:45, Michael Morris wrote:
> >> Please do not quote large swaths of Tony Marston's crap.  He's an
> >> unrepentant liar, braggart and trouble maker that most of the list has
> >> on ignore since the admins can't be bothered to do their job and kick
> >> him.
> >
>
> Just because you don't like what I write does not give you reason to call
> it
> crap.
>
> You call me an unrepentant liar - can you point to anything that I have
> said
> that has proven to be a lie?
>
> You call me a braggart - but at least I have a code base that is still
> going
> strong after 15 years without using any of those optional extras that have
> been added to the language starting with PHP 5.
>
> You call me a trouble maker - what trouble have I made and for whom?
>
> You should learn to keep your insults to yourself.
>
> --
> Tony Marston
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] RFC - Immutable classes

[Chris Riley]

On 2 September 2016 at 15:59, Silvio Marijić 
wrote:

> Michal I'm talking about __clone() callback after clone operation. But I
> agree with you about syntax part.
>
> 2016-09-02 16:46 GMT+02:00 Michał Brzuchalski <
> michal.brzuchal...@gmail.com>
> :
>
> > 02.09.2016 16:29 "Larry Garfield"  napisał(a):
> > >
> > > On 09/02/2016 09:06 AM, Silvio Marijić wrote:
> > >>
> > >> Well at the moment expection is thrown in case when you try to clone
> > >> immutable object. But you do seem to have valid point there regarding
> > >> __clone method. I'm definitely going to give it a thought.
> > >>
> > >> Best,
> > >> Silvio.
> > >>
> > >> 2016-09-02 15:52 GMT+02:00 André Rømcke :
> > >>
> > >>>
> >  On Sep 2, 2016, at 09:10 , Silvio Marijić  >
> > >>>
> > >>> wrote:
> > 
> >  Hi Fleshgrinder,
> > 
> >  Since Michal answered most of the questions, I'll just add some
> notes.
> >  Initially I added restrictions to abstract classes, but I did think
> > about
> >  that over the last couple of days and couldn't find any concrete
> > reason
> > >>>
> > >>> for
> > 
> >  that restriction, so I think I'm going to remove that. As far as
> > cloning,
> >  it is disabled for immutable objects, because you'll end up with the
> > copy
> >  of object that you can not modify. I did mention in Cons sections
> that
> >  cloning is disabled, maybe it should be made more clear.
> > >>>
> > >>>
> > >>> _If_ there are use-cases for it, wouldn’t it also be safe that the
> > clone
> > >>> is allowed to be modified during __clone() and afterwards sealed?
> Like
> > in
> > >>> __construct().
> > >>> And if you don’t want to allow cloning, throw in __clone.
> > >>>
> > >>> Best,
> > >>> André
> > >
> > >
> > > I'd have to agree here.  I love the idea of "lockable" immutable
> > objects.  However, the __clone() method has to be a modifiable area just
> > like __construct() or else it's effectively useless for anything more
> than
> > a trivial object.
> > >
> > > This was one of the main concerns with immutability in the PSR-7
> > discussions.  Consider this sample class, with 8 properties (entirely
> > reasonable for a complex value object):
> > >
> > > immutable class Record {
> > >   public $a;
> > >   public $b;
> > >   public $c;
> > >   public $d;
> > >   public $e;
> > >   public $f;
> > >   public $g;
> > >   public $h;
> > >
> > >   public function __construct($a, $b, $c, $d, $e, $f, $g, $h) {
> > > $this->a = $a;
> > > $this->b = $b;
> > > $this->c = $c;
> > > $this->d = $d;
> > > $this->e = $e;
> > > $this->f = $f;
> > > $this->g = $g;
> > > $this->h = $h;
> > >   }
> > > }
> > >
> > > Now I want a new value object that is the same, except that $d is
> > incremented by 2.  That is, I'm building up the value object over time
> > rather than knowing everything at construct time.  (This is exactly the
> use
> > case of PSR-7.)  I have to do this:
> > >
> > > $r1 = new Record(1, 2, 3, 4, 5, 6, 7, 8);
> > >
> > > $r2 - new Record($r1->a, $r1->b, $r1->c, $r1->d + 2, $1->e, $r1->f,
> > $r1->g, $r1->h);
> > >
> > > That's crazy clunky, and makes immutable objects not very useful.
> Imagine
> > a money object where you had to dissect it to its primitives, tweak one,
> > and then repackage it just to add a dollar figure to it.  That's not
> worth
> > the benefit of being immutable.
> > >
> > > The way PSR-7 addressed that (using fake-immutability, basically), was
> > this:
> > >
> > > class Response {
> > >   // ...
> > >
> > >   protected $statusCode;
> > >
> > >   public function withStatusCode($code) {
> > > $new = clone($this);
> > > $new->statusCode = $code;
> > > return $new;
> > >   }
> > > }
> > >
> >
> > I see only way in somehow invoking closere with cloning. That'll need
> > additional syntax. Clone is left side operator not a function - it's not
> > being called with parenthesis. If this was an object method accessible
> from
> > public it coud gace such closure injected...
> >
> > > That is, outside of the object there's no way to modify it in place,
> but
> > it becomes super easy to get a slightly-modified version of the object:
> > >
> > > $r2 = $r1->withStatusCode(418);
> > >
> > > And because of PHP's copy-on-write support, it's actually surprisingly
> > cheap.
> > >
> > > For language-level immutable objects, we would need some equivalent of
> > that behavior.  I'm not sure exactly what form it should take (explicit
> > lock/unlock commands is all I can think of off hand, which I dislike),
> but
> > that's the use case that would need to be addressed.
> > >
> > > --Larry Garfield
> > >
> > >
> > > --
> > > PHP Internals - PHP Runtime Development Mailing List
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> >
>
>
>
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>

The issue with handling updates on clone to 

Re: [PHP-DEV] [RFC DRAFT] Automatic CSRF Protection

[Chris Riley]

On 10 May 2016 at 17:48, Fleshgrinder  wrote:

> On 5/10/2016 5:24 AM, Yasuo Ohgaki wrote:
> > Hi all,
> >
> > It's not nice to work on the same code (i.e. session module) for
> > multiple RFCs, but time is limited.
> >
> > I would like to hear from ideas/comments before I write patch for this.
> > https://wiki.php.net/rfc/automatic_csrf_protection
> >
> > Thank you for your comments.
> >
> > Regards,
> >
> > P.S. Precise session ID management is important, but this one is also
> > important. I'll finish and start voting 2 active session RFCs soon. I
> > may finish all of them hopefully.
> >
>
> -1 CSRF protection is a very specific need of some parts of a website
> and not something that is universally required.
>
> --
> Richard "Fleshgrinder" Fussenegger
>
>
Sorry but this isn't something that the language should be concerning
itself with. It will cause more pain than it's worth (think magic quotes).

Also, you suggest that PHP should raise an error on session_start if the
validation fails, most of the time if my app gets a csrf failure an error
would be inappropriate as I'd want to handle it myself and display for
example a form validation error message instead of blowing up the whole
script.

Given that this feature is optional it will do nothing to improve security
whilst adding pain to developers who are producing apps designed to run in
multiple environments eg drupal/wordpress etc so a big -1 from me.

Re: [PHP-DEV] Final properties

[Chris Riley]

On 5 April 2016 at 11:57, Michał Brzuchalski  wrote:

> Hi,
>
> 2016-04-05 12:13 GMT+02:00 Marco Pivetta :
>
> > Hi,
> >
> > On 5 April 2016 at 12:06, Michał Brzuchalski 
> > wrote:
> >
> >> Hi Marco,
> >>
> >> Ad. 1 it is posiible to redeclare in a sub-class final property as
> >> non-final, here is some gist presenting my current impl working like:
> >> https://gist.github.com/brzuchal/12ebda1efed59440a78ba43bff116728
> >>
> >
> >
> It works with public, private and protected properties.
>
>
> > Does this work for public properties as well?
> >
> >
> >> Ad. 2. `final` means class variable (like static) or class instance
> >> property can not change their reference, it is impossible to replace
> zval
> >> in such property, in my opinion `immutable` is object behavior when
> using
> >> some methods you receive newly created (cloned) object which is changed
> >> exactly like `DateTimeImmutable`
> >> http://php.net/manual/en/datetimeimmutable.add.php
> >>
> >
> > I am aware of what `final` means in other languages, it just seems that
> > everyone then needs to translate back and forth from `final` to
> > `immutable`. In addition to that, `final` has different meaning in
> > inheritance (re-used keyword), so this adds to the confusion for people
> > unfamiliar with the feature.
> >
> > Wiki about Final in Java
> https://www.wikiwand.com/en/Final_(Java)#/Final_variables says:
>
> # Final variables
> A final variable can only be initialized once, either via an initializer or
> an assignment statement. It does not need to be initialized at the point of
> declaration: this is called a "blank final" variable. A blank final
> instance variable of a class must be definitely assigned in every
> constructor of the class in which it is declared; similarly, a blank final
> static variable must be definitely assigned in a static initializer of the
> class in which it is declared; otherwise, a compile-time error occurs in
> both cases.[6] (Note: If the variable is a reference, this means that the
> variable cannot be re-bound to reference another object. But the object
> that it references is still mutable, if it was originally mutable.)
>
> I took the name from Java and only implemented behavior like that, thats wy
> I used `final`.
>
>
> >> Ad. 3 it would be awesome if there could be final variables in general,
> >> it would be quite stable if no one could change your variable, AFAIK
> zvals
> >> have IMMUTABLE flag which could be used, don't know it for sure I'm
> rather
> >> PHP dev than C there would be need some internals guru to ask if it's
> >> posiible.
> >>
> >> P.S. We've meet on PHPCon'15 in Poland, thanks for +1.
> >>
> >
> > YW!
> >
> >
> >>
> >> Cheers,
> >> --
> >> Michał Brzuchalski (aka brzuchal)
> >>
> >> 2016-04-05 11:13 GMT+02:00 Marco Pivetta :
> >>
> >>> Hi Michał,
> >>>
> >>> First of all: +1 to this: very useful for value objects!
> >>>
> >>> A few questions:
> >>>
> >>>  * can you re-declare a final property in a sub-class, making it
> >>> therefore non-final? (I have reasons to do that, related with altering
> >>> states via mappers)
> >>>  * do we want to use `final`, or `immutable` for these properties?
> >>> `final` seems to just be a confusing term here.
> >>>  * is this feature portable to variables in general? I realize that
> >>> adding metadata to ZVals has huge performance implications, but it
> would be
> >>> interesting to do that for performance improvements further down the
> line
> >>>
> >>> Cheers,
> >>>
> >>>
> >>> Marco Pivetta
> >>>
> >>> http://twitter.com/Ocramius
> >>>
> >>> http://ocramius.github.com/
> >>>
> >>> On 4 April 2016 at 19:53, Michał Brzuchalski 
> >>> wrote:
> >>>
>  Hey Internals,
> 
>  I'm new here. I've been wondering / working on adding final properties
>  into
>  PHP lang.
> 
>  This work started once I had the time to read the "Core Java for
>  Impateient" by Cay S. Horstmann
>  and found it very usefull to have final properties like Java.
> 
>  Those properties differ than `const` because they can be set at
> runtime
>  -
>  but only once in their lifetime.
>  Such properties could be very usefull in Singletons, ValueObjects etc.
>  impl
>  like:
> 
>  class Money {
>  public final $amount;
>  public final $currency;
>  public function __constructor($amount, $currency) {
>  $this->amount = $amount;
>  $this->currency = $currency;
>  }
>  }
> 
>  In above example there is even no need for getter because those
>  properties
>  are immutable through
>  the final keyword, it means those properties cannot change their
>  references
>  just like in Java
>  https://en.wikipedia.org/wiki/Final_(Java)
> 
>  I've already started some impl on own fork
> 
> 
> 

Re: [PHP-DEV] #71915 openssl_random_pseudo_bytes is not "fork-safe"

[Chris Riley]

On 29 March 2016 at 19:49, Jakub Zelenka  wrote:

> I have added some feedback and assigned it to myself ;)
>
> On Tue, Mar 29, 2016 at 3:05 PM, Tom Worster  wrote:
>
> > mathieuk has requested feedback on a patch to mitigate this problem in
> PHP.
> >
> > https://bugs.php.net/bug.php?id=71915
> >
> > Tom
> >
> >
> >
>

Would the safest option here not just be upon fork, reseed the RNG from
/dev/urandom ?

Re: [PHP-DEV] Forbid binding methods to incompatible $this

[Chris Riley]

On 29 March 2016 at 23:21, Nikita Popov  wrote:

> Hi internals!
>
> Currently, inside instance methods the following invariant holds:
>
> assert(is_null($this) || is_object($this))
>
> This is a problem. I'd like to guarantee the following invariant instead:
>
> assert(is_null($this) || $this instanceof self)
>
> That is, ensure that if $this is not null, then it must be an object
> "compatible" with the class, i.e. be in its inheritance hierarchy.
>
> The absence of this guarantee, apart from being a major WTF in itself, also
> prevents us from optimizing operations involving $this. In particular, the
> following optimizations are not possible:
>
> a) If typed properties land, we will not be able to use the type of
> $this->typedProperty for optimization, because $this->typedProperty might
> actually be referencing a property of a totally unrelated class.
> b) We are not able to early-bind arguments to private or final method
> calls, i.e. determine at compile-time whether an argument will use by-value
> or by-reference argument passing and optimize accordingly.
> c) We are not able to inline calls to private or final methods. (The
> possibility of null is an issue in this instance as well, though a lesser
> one.)
>
> The good news is that, as of PHP 7.0, we are *very* close to guaranteeing
> that "$this instanceof self" already. There exists only one little known
> loophole: Obtaining a closure object wrapping the method using
> ReflectionMethod::getClosure() and binding to an unrelated $this using
> Closure::bindTo().
>
> In PHP 7.0 we already heavily cut down [1] on what bindTo() is to allowed
> to do on fake method closures. Namely, it was completely forbidden to
> rebind the scope of methods, as this was already interacting badly with
> optimizations in 7.0. We did not forbid binding to an incompatible $this
> because it was not yet causing immediate issues at the time.
>
> I'd like to remedy this oversight now and restrict $this binding of fake
> method closures to compatible contexts only, i.e. for a method A::foo()
> allow only instances of A or one of its descendant classes to be bound.
> This limitation already exists for fake method closures targeting internal
> methods.
>
> Are there any objections to this change? If not, I'll merge the patch [2].
> If yes, I'll write an RFC, as this change, while of no direct consequence
> for PHP programmers, is important for the PHP implementation.
>
> Regards,
> Nikita
>
> [1]: http://markmail.org/message/sjihplebuwsmdwex
> [2]:
> https://github.com/php/php-src/compare/master...nikic:forbigIncompatThis
>


Hi,

Will this patch break any use cases similar to:

class Bar {
private $a = 'hidden';
}

$x = new Bar();
$y = function() { return $this->a);
$z = $x->bindTo($x, $x);
echo $z(); //hidden

?

If not, I have no objections.

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

[Chris Riley]

You are right, perhaps this should be controlled simply by an ini flag:
session https only.

On Mon, 28 Mar 2016, 01:09 Stanislav Malyshev,  wrote:

> Hi!
>
> >> Could we also add HTTPS detection and enable the secure flag by default
> >> when a session is established on an HTTPS endpoint?
>
> You can not see if your connection would be HTTPS or not - connection
> can be terminated on frontend services (like nginx or varnish) that
> handle https and the pass the actual work to backend like fpm or apache
> or whatever it is. In this situation, you may have no information about
> if the connection to the client is HTTPS or not.
>
> And in general, AFAIK there is no standard protocol to establishing this
> kind of info. There are all kinds of ways people do it, but each of them
> is peculiar for specific setup.
>
> I also think it is a mistake to have default behavior controlled by
> external factors beyond server admin's control. Server behavior should
> be predictable. The admin should set it up properly, if the admin is not
> knowledgeable enough to set it up, I don't think we can improve it by
> introducing variable defaults into the mix.
> --
> Stas Malyshev
> smalys...@gmail.com
>

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

[Chris Riley]

On 24 March 2016 at 14:43, Scott Arciszewski <sc...@paragonie.com> wrote:

> On Thu, Mar 24, 2016 at 9:55 AM, Chris Riley <t.carn...@gmail.com> wrote:
>
>> On 24 March 2016 at 02:34, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>>
>> > Hi all,
>> >
>> > Since the vote for
>> > https://wiki.php.net/rfc/precise_session_management
>> > is declined 15 vs 11.
>> > https://wiki.php.net/rfc/precise_session_management#vote
>> >
>> > We have to come up with other solutions for
>> >
>> >  - Session loss by race conditions
>> >  - Method to make session abuse harder
>> >
>> > I'm open to implement better solution than proposed RFC.
>> >
>> > These issues are serious issues that cannot be ignored.
>> > Looking forward alternative implementation ideas!
>> >
>> > Thank you.
>> >
>> > --
>> > Yasuo Ohgaki
>> > yohg...@ohgaki.net
>> >
>> > --
>> > PHP Internals - PHP Runtime Development Mailing List
>> > To unsubscribe, visit: http://www.php.net/unsub.php
>> >
>> >
>> I'm disappointed this RFC failed as improving session security should be a
>> high priority. I'd propose that we focus on items which will improve
>> session security overall. This jumped out at me to start with: "This RFC
>> also
>> includes minor security improvements like httponly cookie, better hash
>> function."
>>
>> Perhaps a first RFC for improving session security can start with those
>> items: Set the session cookie to be httponly (or provide an ini setting to
>> do so, defaulting to on) instead of using a better hash function for the
>> session id, why not generate it from random_bytes()? Then the id is crypto
>> secure.
>>
>> I'd then consider a second RFC setting out the extra internal data that
>> would be required to kill off old sessions correctly. That would require
>> to
>> keys under ['__PHP__SESSION__'] (could the key name be an ini setting to
>> preserve BC?) 'destroyed' and 'expires', the latter would be a bool flag
>> stating if the session had been explicitly destroyed. (A destroyed session
>> could no longer be used, could throw an exception or just have no data in
>> it) the expires key would be used in a similar manner, being set to
>> Time+cookie expiry time on each read/write to the session. (again an
>> expired session would not be accessible and would function like a
>> destroyed
>> one)
>>
>> The combination of the two would resolve most of the security issues and
>> establish the __PHP__SESSION__ key which could later be used to handle the
>> race condition issue.
>>
>
> Could we also add HTTPS detection and enable the secure flag by default
> when a session is established on an HTTPS endpoint?
>
> Scott Arciszewski
> Chief Development Officer
> Paragon Initiative Enterprises <https://paragonie.com/>
> ​
>
>
I had considered this suggestion myself, but I wasn't sure if it would be
easy to implement. It could also cause some very strange (to a novice
developer) behaviour which would be hard to debug (Think sites which have
part http part https, session behaviour would be dependant on the entry
page the user hits) I'd support this, but it should probably be opt-in to
start with (alternatively we could come up with a different way to allow
the developer to specify sessions being ssl only)

Re: [PHP-DEV] [RFC][Discussion] Precise session data management

[Chris Riley]

On 24 March 2016 at 02:34, Yasuo Ohgaki  wrote:

> Hi all,
>
> Since the vote for
> https://wiki.php.net/rfc/precise_session_management
> is declined 15 vs 11.
> https://wiki.php.net/rfc/precise_session_management#vote
>
> We have to come up with other solutions for
>
>  - Session loss by race conditions
>  - Method to make session abuse harder
>
> I'm open to implement better solution than proposed RFC.
>
> These issues are serious issues that cannot be ignored.
> Looking forward alternative implementation ideas!
>
> Thank you.
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm disappointed this RFC failed as improving session security should be a
high priority. I'd propose that we focus on items which will improve
session security overall. This jumped out at me to start with: "This RFC also
includes minor security improvements like httponly cookie, better hash
function."

Perhaps a first RFC for improving session security can start with those
items: Set the session cookie to be httponly (or provide an ini setting to
do so, defaulting to on) instead of using a better hash function for the
session id, why not generate it from random_bytes()? Then the id is crypto
secure.

I'd then consider a second RFC setting out the extra internal data that
would be required to kill off old sessions correctly. That would require to
keys under ['__PHP__SESSION__'] (could the key name be an ini setting to
preserve BC?) 'destroyed' and 'expires', the latter would be a bool flag
stating if the session had been explicitly destroyed. (A destroyed session
could no longer be used, could throw an exception or just have no data in
it) the expires key would be used in a similar manner, being set to
Time+cookie expiry time on each read/write to the session. (again an
expired session would not be accessible and would function like a destroyed
one)

The combination of the two would resolve most of the security issues and
establish the __PHP__SESSION__ key which could later be used to handle the
race condition issue.

Re: [PHP-DEV] RFC about automatic template escaping

[Chris Riley]

Honestly, as it stands this is a pretty terrible idea.

1. It has a huge potential for introducing BC breaks.
 -  I have some code somewhere which uses output buffering and echo to
write cached copies of html pages to disk. This would break that.
 - Writing out html like structures when running as a cli shouldn't be
affected; but it probably would be.
 - Several systems store html templates in a database and echo them.
Possible breaking change here
2. Relying on an ini setting for security is a bad idea: we did that with
magic quotes and look how that turned out.
3. Ini setting changes at runtime cannot be relied upon. (Think shared
hosting providers who might switch this on(or off) globally and deny
changes to it at runtime)
4. Already mentioned but there is more to escaping than just HTML

If you decide to pursue this further try using
declare(this_is_a_template=true) at the top of each template file to enable
this badhaviour instead of an ini setting. This then applies on a per file
basis and side steps numerous issues.

Re: [PHP-DEV] [RFC Discussion] Typed Properties

[Chris Riley]

On 16 March 2016 at 17:17, Bob Weinand  wrote:

> Hey, thank you both for investing your time :-)
> Property types are definitely interesting.
>
> > Am 16.03.2016 um 17:36 schrieb Phil Sturgeon :
> >
> > Hello everyone,
> >
> > I have completed the draft for an RFC, to add Typed Properties. The
> > patch has been written by the one and only Joe Watkins.
> >
> > https://wiki.php.net/rfc/typed-properties
> >
> > I would really appreciate constructive feedback on this RFC, with a
> > few areas especially:
> >
> > 1. How scared are we that integers can be expanded to floats on runtime?
>
> This IMHO is quite necessary, for the same reasons why we even allow int
> to float widening with strict return types.
>
> class foo {
> float $bar;
> function __construct(int $x) {
> assert($x > 0);
> $this->bar = 10 / $x;
> }
> }
>
> This is perfectly innocuous, but will fail for values 1, 2, 5 and 10, if
> we don't allow widening.
> Depending on the values it might also be not caught in testing.
>
> > 2. This whole temporary nullability situation, where unset properties
> > will error on attempted usage if not set. Should they instead error
> > after the constructor has been called if they are still not holding a
> > value?
>
> Erroring when using the unset property is the way to go.
>
> The example from the RFC is showing exactly why...
>
> class Foo {
> public int $foo;
> }
> $foo = new Foo();
> echo $foo->foo; // Patch currently errors here
>
> With one property, not so much an issue, we could force a constructor.
> But with 20 properties, definitely an issue.
>
> If we'd error after constructor call, there are also other complications…
>
> class Foo {
> public int $bar;
> function __construct() {
> global $foo;
> $foo = $this;
> }
> }
> try {
> new Foo;
> } catch (Error $e) {}
> var_dump($foo->bar); // not set, but instance is referenced
>
> Sure, we could find ways to circumvent that and change the class to
> totally non-functional and making every usage of it throw an Error, but it
> isn't quite elegant.
>
> > 3. Weak vs Strict. Right now this is entirely strict, with no
> > declare() to change mode. Reasons for this vary, from various sources,
> > but include "Not sure how to implement it" and "Well people should not
> > be using properties as part of their public API".
> >
> > Help on 3 would be appreciated.
>
> Now, if we already have int to float widening (which I recommend), we
> anyway need to do certain checks.
> At that point we can just as well add weak typing, because, why not?
>
> We do not have an exceptional handling for return types (which are even
> more subject to be strict-only as it is function-local — properties may be
> public). And so we shouldn't have either for property types.
>
> Thus, my recommendation is to be consistent regarding strict and weak
> typing regarding argument and return types.
>
> > Also let's please avoid "PHP IS TURNING INTO JAVA" and the other
> > rather common rhetoric. Strict Type Hinting might have been seen as a
> > battleground for fans of strict and fans of weak to fight through a
> > keyboard, but this RFC will not be the repeat.
> >
> > We'll have a nice, orderly, constructive conversation about this RFC,
> > and improve the patch as you all provide feedback.
> >
> > Let me know what you think folks!
>
> Thanks,
> Bob
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'm not 100% convinced that we need this now we have full type hint support
for parameters and return types; but it does have potential to remove
boiler plate for public properties. For point 2 nullable properties, how
about some syntax which allows for a property to be null, or for it to be a
specific type. I'd suggest a null assignment to fall in line with parameter
type hints eg:

class Foo {
protected int $bar = null; //can be null
private stdClass $baz; //can't be null
}

Re: [PHP-DEV] [RFC][VOTE] Deprecate then Remove Mcrypt

[Chris Riley]

On 15 March 2016 at 17:40, Will Fitch  wrote:

>
>
> On Tue, Mar 15, 2016, at 12:18 PM, Ferenc Kovacs wrote:
> > On Tue, Mar 15, 2016 at 6:13 PM, Scott Arciszewski 
> > wrote:
> >
> > > On Tue, Mar 15, 2016 at 1:09 PM, Ferenc Kovacs 
> wrote:
> > >
> > >>
> > >>
> > >> On Tue, Mar 15, 2016 at 5:11 PM, Scott Arciszewski <
> sc...@paragonie.com>
> > >> wrote:
> > >>
> > >>> Hi PHP team,
> > >>>
> > >>> I've opened the vote on
> https://wiki.php.net/rfc/mcrypt-viking-funeral
> > >>> which aims to deprecate ext/mcrypt in PHP 7.1 then remove it in 7.1+1
> > >>> (i.e.
> > >>> make it only installable via PECL).
> > >>>
> > >>> In the interim, I'll be developing a (MIT licensed) decryption-only
> > >>> userland implementation of the mcrypt ciphers so people can migrate
> their
> > >>> code towards something better.
> > >>>
> > >>> This vote is opened on March 15th, 2016 and will close March 22th at
> > >>> 17:00
> > >>> UTC.
> > >>>
> > >>> (Sidenote: Apologies for the brief unannounced hiatus from
> participating
> > >>> here.)
> > >>>
> > >>> Scott Arciszewski
> > >>> Chief Development Officer
> > >>> Paragon Initiative Enterprises 
> > >>>
>
> In the RFC:
>
> "Removal from core: The following major/minor version (7.2.0 or 8.0.0)"
>
> and then
>
> "Vote “Yes” to raise an E_DEPRECATED notice in PHP 7.1 when any mcrypt
> function is used and to remove the extension from core in 7.1+1."
>
> Which one is it? I feel removing at 7.2 would be too soon.  I agree that
> the abandonware is a nuisance, but many developers using ext/mcrypt have
> no idea of this.  Raising an E_DEPRECATED in the next 7.1.x, then
> removing in 7.2 is just too soon.
>
>
I disagree. It's not like we are obliterating the functionality from the
face of the planet, any user requiring mcrypt in 7.2+ can fully aware of
the consequences, install it from PECL. Also, bear in mind that some linux
distros (RHEL) have already dropped mcrypt support.

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

[Chris Riley]

On 24 February 2016 at 22:04, Chase Peeler <chasepee...@gmail.com> wrote:

>
>
> On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner <kgess...@etsy.com> wrote:
>
>> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley <t.carn...@gmail.com> wrote:
>>
>> > This isn't such a great idea as it will cause some of traits
>> functionality
>> > to be broken: I can currently use a trait and alias its methods and
>> change
>> > their visibility. If a trait implements an interface which is copied
>> onto
>> > my class I can no longer do this as the compiler will throw a fatal
>> error
>> > for the class not correctly implementing the interface that got copied
>> from
>> > the trait.
>> >
>>
>> This is only true under Proposal 2 of the RFC, and this is listed as an
>> open issue: https://wiki.php.net/rfc/traits-with-interfaces#proposal_2
>>
>> Proposal 1, where the engine enforces interface declarations on traits,
>> doesn't affect how traits are inserted and still allows aliasing.
>>
>>
>> > If you decide to continue pursuing this RFC, I'd like to see some
>> thought
>> > given to the above; perhaps it could be as simple as not copying the
>> > interface if aliases/visibility changes are made in the use or perhaps
>> > something more complex which allows specifying which interfaces should
>> be
>> > copied into the class from the trait.
>> >
>>
>> I agree that there are several reasonable solutions here, but I'm not sure
>> which is the best.  It does feel too aggressive to have it be a fatal
>> error
>> if aliasing undoes the interface implementation.  At the same time,
>> introducing new syntax to enable aliasing to work with interface
>> propagation defeats the purpose, which is to make it easier and simpler to
>> implement an interface via a trait.
>>
>> I'd be interested to hear if you have any ideas about how this should
>> look.  I'm mostly unfamiliar with aliasing traits in practice, so I'd be
>> curious to see how this RFC would affect your code.
>>
>> Since the class doesn't know you are using the trait to implement the
> interface, if you alias the trait method, then the class no longer
> implements the interface unless it defines the method that is now missing
> itself.
>
> Remember, the contents of the trait are just getting copy/pasted into the
> class. If you alias a method, then the method gets pasted in using the
> alias, not the original name.
>
> That being said, it should be rare that you would alias a method and then
> not implement the method yourself - as the need to redefine/expand on its
> functionality is the reason you usually alias a trait method.
>
>
>
>> Cheers
>> -- Kevin
>>
> --
> -- Chase
> chasepee...@gmail.com
>

Aliasing isn't something I use often; however changing visibility is - such
that the methods in the trait become an implementation detail for the class
in question and don't pollute it's public API. That would break if an
interface was copied onto my class.

Re: [PHP-DEV] Re: [RFC] Traits with interfaces

[Chris Riley]

On 23 February 2016 at 00:37, Alex Bowers  wrote:

> Would a fair solution to this be having the using class define whether to
> inherit the implementations? Perhaps a new keyword akin to 'propagated', so
> the code will read
>
> Class Foo {
>Use propagated TraitName;
> }
>
> Only then will the implementations from that trait bubble through. If it
> isn't declared then the implementations are not visible. This should keep
> all backwards compatibility and keep code readable since now we can
> immediately tell which traits being used do we want the implementations for
> in the main class.
> On 22 Feb 2016 20:19, "Kevin Gessner"  wrote:
>
> > On Thu, Feb 18, 2016 at 4:13 PM, Kevin Gessner 
> wrote:
> >
> > > On Wed, Feb 17, 2016 at 2:05 PM, Kevin Gessner 
> > wrote:
> > >
> > >> I've created a proper RFC wiki page here with the draft:
> > >> https://wiki.php.net/rfc/traits-with-interfaces
> > >>
> > >> It includes more detail and several example code snippets.  Thanks all
> > >> for your feedback so far.
> > >>
> > >
> > > I've just updated the RFC to v0.2, presenting two proposals to be voted
> > > separately: one to allow traits to declare and implement interfaces,
> and
> > a
> > > second (dependent on the first) to propagate interface declarations
> from
> > > traits to classes.
> > >
> >
> > I've created a php-src pull request for Proposal 1 of the RFC, allowing
> > traits to declare and implement interfaces:
> > https://github.com/php/php-src/pull/1773
> >
> > Reviews and feedback welcome!
> >
> > I haven't yet started on an implementation for Proposal 2.
> >
> > Cheers
> > -- Kevin
> >
>

This isn't such a great idea as it will cause some of traits functionality
to be broken: I can currently use a trait and alias its methods and change
their visibility. If a trait implements an interface which is copied onto
my class I can no longer do this as the compiler will throw a fatal error
for the class not correctly implementing the interface that got copied from
the trait.

If you decide to continue pursuing this RFC, I'd like to see some thought
given to the above; perhaps it could be as simple as not copying the
interface if aliases/visibility changes are made in the use or perhaps
something more complex which allows specifying which interfaces should be
copied into the class from the trait.

~C

Re: [PHP-DEV] Re: [RFC] [Re-proposed] Adopt Code of Conduct

[Chris Riley]

On 22 January 2016 at 14:29, Pierre Joye  wrote:

> On Jan 22, 2016 7:03 PM, "Derick Rethans"  wrote:
>
> Freshly adopted:
>
> http://rubyonrails.org/conduct/
> https://golang.org/conduct
>
> I like both with a very good special mention for the Go one for its clarity
> and completeness.
>
> Cheers,
>

This caught my eye earlier as being relevant:
http://meta.stackoverflow.com/questions/315092/why-is-being-honest-getting-penalized-these-days
and SO's policy: http://stackoverflow.com/help/be-nice

~C

Re: [PHP-DEV] PHP 7.1 - Argon2

[Chris Riley]

On 11 January 2016 at 09:12, Rouven Weßling  wrote:

>
> > On 11 Jan 2016, at 07:57, Scott Arciszewski  wrote:
> >
> > Does adding Argon2 as a possible choice for password_hash() +
> > password_verify() need an RFC? Or can I just submit a pull request?
>
> The original RFC (https://wiki.php.net/rfc/password_hash) contained the
> following text:
>
> > I'd propose the following policy for updating the default hashing
> algorithm in future releases of PHP.
> >
> > * Any new algorithm must be in core for at least 1 full release of PHP
> prior to becoming default. So if scrypt is added in 5.5.5, it wouldn't be
> eligible for default until 5.7 (since 5.6 would be the full release). But
> if jcrypt (making it up) was added in 5.6.0, it would also be eligible for
> default at 5.7.0.
> > * The default should only change on a full release (5.6.0, 6.0.0, etc)
> and not on a revision release. The only exception to this is in an
> emergency when a critical security flaw is found in the current default.
> > * For a normal (non-emergency) change in default, an RFC shall be issued
> for the update of the default algorithm, following normal RFC rules.
>
> So technically I don’t think it would be necessary to have an RFC to add
> another algorithm, though I think it might be nice as this is certainly a
> place where things shouldn’t be changed willy nilly.
>
> > It won't be changing the default in 7.1, and IIRC this sort of change
> > was already agreed upon as part of the original password_hash() RFC.
>
> I’m not really qualified to discuss the merits of the algorithm but a
> couple of questions:
>
> * Is there already a crypt scheme for Argon2? Or are there any efforts to
> define one? It would good if PHP wouldn’t be an island.
> * Back in July, when it won the PHC, it wasn’t deemed production ready as
> they wanted to make a few tweaks. Is that completed?
> * Are you proposing to use Argon2d or Argon2i?
>
> Lastly, I think it would be a good start to implement Argon2 in ext-hash.
>
> Best regards
> Rouven
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I was considering the same for adding scrypt; however there (isn't|wasn't|I
couldn't find) a crypt scheme for it and having a custom algorithm
identifier for php seemed like a bad idea.

~C

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Chris Riley]

On 5 January 2016 at 16:15, Anthony Ferrara  wrote:

> All,
>
> On Mon, Jan 4, 2016 at 4:06 PM, Anthony Ferrara 
> wrote:
> > Hey all,
> >
> > I have created a new RFC for the PHP Project to adopt the Contributor
> > Covenant as the official Code of Conduct for the project
> >
> > https://wiki.php.net/rfc/adopt-code-of-conduct
> >
> > Let me know what you think or if there are any concerns
> >
> > Thanks
> >
> > Anthony
>
> In response to significant feedback here and elsewhere, I have
> expanded the text of the RFC significantly. It now includes the text
> of the Contributor Covenant 1.3.0 as well as including verbage about
> updating it requiring an RFC.
>
> I included a vote requirement for course of actions of 4/5 of the CoC team.
>
> I also included content about the "Reasonable Person Test", explicitly
> stating that it shall be assumed that both parties are acting as
> reasonable people until proven otherwise by significant evidence. It
> also stipulates that reporting an incident does not excuse someone
> from the CoC (meaning victims are still bound to follow it, and are
> not excused from proper behavior because of a violation).
>
> I also made it explicit that potential actions should be a last
> resort, and that the CoC team should make every reasonable attempt to
> defuse the situation without having to resort to "punishment".
>
> I also removed the ability to remove commit karma from the team,
> instead including that in the "ban" category (meaning that the CoC
> team is no longer allowed to remove commit karma long-term without the
> action of internals@)
>
> Additionally, I added a line specifying that bans (temporary or
> permanent) should only be used in egregious cases.
>
> I added a section on transparency, Conflict of Interest (though this
> needs expanding) and accountability (giving internals@ the ability to
> "overturn" any action by the CoC team with a vote of 50%+1). I also
> made it explicit that accused people have a right to confidentiality
> as long as no action is taken by the team.
>
> I also added a section on appeals.
>
> Those are the changes to the RFC as it stands. Please review them.
>
>
>
> As to the comments in this thread, I won't reply to every one, but
> here are a few points I'd like to make.
>
> It's been mentioned that we may want to adopt a CoC, but it shouldn't
> "have teeth". I disagree here, as without an enforcement mechanism it
> basically is no different from where we are at today. Saying we should
> act reasonable is fine, but we need a method for what we are to do
> when one of us acts unreasonably. Additionally, as has been stated,
> requiring people to report publicly creates a barrier to entry. Many
> people will simply chose to leave quietly rather than report publicly.
> Simply look at the way people who speak out about harassment are
> treated in public to understand why. The point of the CoC is to create
> a safe place for everyone to contribute, not just those with thick
> skin.
>
> As to why the Contributor Covenant as opposed to another CoC or our
> own custom one, there are two reasons for this. First, it's a standard
> that's been adopted by a number of significant scale projects. Second,
> it saves us from having to bikeshed over every single word of a CoC.
> If there's another standard CoC that we should entertain, I'm happy to
> look at it. But I do not believe that we should create our own.
>
> As far as the conflict resolution process, that I am open to expanding
> or retracting as much as practical. I do think it's important to have,
> but would be happy to take advice from groups like Drupal who have
> done this before.
>
> To those that say this is a solution in search of a problem, it very
> well may be. But that doesn't mean it isn't important to do. You could
> say the same thing about smoke detectors. Even if you've never had a
> fire, that doesn't mean it isn't good practice to install protection
> from one. In this case, we simply do not know if or how many
> contributors we may have lost due to incidents covered by a CoC. Even
> if that number is 0, does that mean it's not worth installing one to
> prevent it in the future?
>
> Thanks,
>
> Anthony
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
I'd suggest we consider using drupals CoC as a model; it has a more
positive tone.

Additionally, given that this CoC has far reaching consequences, I would
suggest opening up voting on it's implementation to a wider segment of the
community eg those currently subscribed to the PHP mailing lists or at
least those who have recently participated on one.

~C

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

[Chris Riley]

On Tue, 5 Jan 2016, 18:20 Ferenc Kovacs  wrote:

>
>> Additionally, given that this CoC has far reaching consequences, I would
>> suggest opening up voting on it's implementation to a wider segment of the
>> community eg those currently subscribed to the PHP mailing lists or at
>> least those who have recently participated on one.
>>
>> ~C
>>
>
> wouldn't that allow sock puppeting and vote brigading?
>
> --
> Ferenc Kovács
> @Tyr43l - http://tyrael.hu
>

And that won't happen on this rfc regardless?

>

Re: [PHP-DEV] Benchmark Results for PHP Master 2015-12-17

[Chris Riley]

On 18 December 2015 at 02:39, Good Guy  wrote:

> On 18/12/15 02:15, Yasuo Ohgaki wrote:
>
>> The objective of this benchmark is to alert developers accidental
>> performance drop. Even small change may affect performance a lot. This
>> would be good enough for the purpose. IMO. Regards, -- Yasuo Ohgaki
>>
>
> I would like to see Joomla 3.4.6  and Drupal 8.0 included in this test.
>
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Perhaps we could limit it to only send emails if there has been a big
performance drop - that way people would read it rather than dismiss it as
'just todays benchmark email'

Re: [PHP-DEV] PHP 7.0.0 final RTM delay

[Chris Riley]

On 4 December 2015 at 13:54, Lester Caine  wrote:

> On 04/12/15 10:29, Sebastian Bergmann wrote:
> >> Windows as a platform is different from Linux/Mac in several aspects
> >  True. But why does the PHP Project have to provide Windows binaries on
> >  php.net? Microsoft should be treated as any other downstream vendor:
> let
> >  them build their binaries on their infrastructure and let them
> distribute
> >  their binaries through their channels.
>
> I think the problem in the past has been that simply compiling on a
> windows machine required both proprietary software and an understanding
> of areas that a new user would not normally encounter. Things have
> changed and we can download a free environment to create a windows build
> almost as easily as building on any Linux distribution. That ONLY works
> because Pierre and others have sorted out all the problems with the
> build process, and the binaries are almost a free result of the QA
> process. It would be nice if Apache was also available as an official
> windows build since that can still be difficult to build privately on
> windows and is the main reason ApacheLounge came into existence.
>
> Yes providing windows binaries is not essential but it does at lease
> ensure that one is helping a windows php newbie one knows exactly what
> they have installed. Personally I've migrated to only running PHP on
> Linux these days but I still have to support windows only sites and
> appreciate the binary builds.
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
If anyone feels strongly one way or another about providing binary releases
for different platforms; why not create an RFC and vote on it?

~C

Re: [PHP-DEV] HashDos protection

[Chris Riley]

On 1 December 2015 at 09:50, Dmitry Stogov  wrote:

> Hi Nikita,
>
> few notes:
>
> It looks like the patch messes the attempt of catching the problem (few
> lines related to zend_hash_find_bucket changes) with optimization to
> compensate collision check overhead (everything else). I think it's better
> to separate these parts.
>
> Introduction of zend_hash_add_or_return() in 7.0.1 is going to make forward
> incompatibility with 7.0.0. However, we may reserve it for internal usage
> removing ZEND_API.
>
> I don't think PHP should prevent user from construction of arrays he likes,
> because of internal problems (like in your example).
>
> >  $s = 1 << 16; $a = [];
> >  for ($i = 0; count($a) < $s; $i += $s) { $a[$i] = 0; }
>
> It makes performance problem, but it doesn't mean we should kill it.
> We have "max_execution_time" to catch them all.
>
> I think only big arrays coming from external sources should be checked.
>
> Your solution is incomplete, anyway, because of crafting a single list with
> 1 collisions, attacker will able to use N lists with 1000 collisions.
>
> Thanks. Dmitry.


This is a good point but bear in mind to get the same effect as for 1
collisions, you'd need 100 lists not 10

Re: [PHP-DEV] RE: HashDos protection

[Chris Riley]

On 28 November 2015 at 01:00, Pascal KISSIAN 
wrote:

> -Message d'origine-
> De : Nikita Popov [mailto:nikita@gmail.com]
> Envoyé : jeudi 26 novembre 2015 18:25
> À : PHP internals; Anatol Belski; Remi Collet
> Objet : HashDos protection
>
> >Hi internals!
> >his mail turned out to be rather long, so I'll start with a TL;DR:
>
> >To fix the HashDos vulnerability for *all* cases (rather than just
> GET/POST parsing), I propose to introduce collision counting during
> hashtable insertion operations. This will throw a fatal error if the number
> of collisions during an insertion operation exceed a certain threshold.
>
> >In PHP 5.3.9 a partial fix for the HashDos vulnerability was introduced
> in the form of max_input_vars.
>
> Hi everybody...
> I am very new to this mailing list, and I do not know If my thinking about
> this problem is good, but to my opinion, this kind of attack is based on
> the fact that the hacker knows in advance how to compute the hash value in
> order to generate collision.
>
> If a random salt was added in the _zend_array struct (at a cost of the
> salt size 4 bytes? for each hash table),
> Then if  the hash computation takes that salt into account ( add ht
> parameter to each function that calculates the hash)
> It would be impossible to predict the hash of a value.
> So impossible to perform such kind of attack...
>
> What do you think about that ?
>
> Perhaps if you do not want to increase the size of the the _zend_array
> struct, perhaps a random salt initialized at the init of a php program (the
> same for all hash tables, that changes at each run) could be enough!
>
> Best regards,
> Pascal KISSIAN
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
As a bare minimum, such a salt would need to be Xor'd with the string
before hashing simple addition still produces collisions. I suspect it
would still be easy to produce collisions, however my math is not good
enough (at least not on a Monday morning) to figure out how.

[PHP-DEV] Pear.php.net SSL cert

[Chris Riley]

Anyone else getting an invalid cert on https://pear.php.net ?

Re: [PHP-DEV] RE: HashDos protection

[Chris Riley]

On 30 November 2015 at 13:58, Pascal KISSIAN 
wrote:

> >De : Nikita Popov [mailto:nikita@gmail.com]
> >Envoyé : dimanche 29 novembre 2015 12:45
> >À : Pascal KISSIAN
> >Cc : PHP internals
> >Objet : Re: HashDos protection
>
> >Collisions in DJBX33A are (integer overflow notwithstanding) completely
> independent of the starting value, so randomizing it wouldn't help. If
> you're interested in how DJB collisions are constructed, see
> http://www.phpinternalsbook.com/hashtables/hash_algorithm.html#hash-collisions
> .
>
>
>
>   Very interesting reading, thanks…
>
>
>
>
>
>
>
> >Similarly, this would not have any effect either. We reduce hashes using
> an equivalent of hash % table_size, which is the same as (hash + N *
> table_size) % table_size for any N. If you simply add an additional number
> to it, the same relation still holds: (hash + salt) % table_size == (hash +
> salt + N * table_size) % table_size, so elements that collided previously
> still collide.
>
>
>
> You’re absolutely right!  Just adding something results in a translation
> of the hash table cell…
>
> Perhaps another operation could do the job?  Multiply still keeps the
> collision for the modulo equal to 0… perhaps add + multiply ….
>
>
>
> However, my main feeling is that "An ounce of prevention is worth a pound
> of cure"…
> … and my preferences will go to your second option …  taking care of not
> degrading performance…
>
>
>
> pk
>
>
As for what other languages do, Python, Ruby and Perl all seem to have
switched to using sipHash - maybe we should consider this too

Re: [PHP-DEV] Native Annotation Syntax

[Chris Riley]

On 26 November 2015 at 16:05, guilhermebla...@gmail.com <
guilhermebla...@gmail.com> wrote:

> Ok then. I'll pretend that lack of interest didn't happen many other
> situations (like http://marc.info/?t=14460876781) and move on.
>
> I don't want to bring the patch up to date/simplify it without a clear
> decision of at least be willing to discuss the patch and not reject by all
> means.
> I'd propose a voting as "Are you ready for Annotations yet?". Every core
> developer understands (and can base their decisions) by looking at the
> complexity of the old patch.
>
> Once voting completes and IF it gets approved, I'll gladly put it up to
> date for consideration and update the RFC.
>
> []s,
>
> On Thu, Nov 26, 2015 at 10:53 AM, Rowan Collins 
> wrote:
>
> > guilhermebla...@gmail.com wrote on 26/11/2015 15:14:
> >
> >> I haven't seen any user asking for traits
> >>
> >
> > Just because you didn't see it, doesn't mean it didn't happen.
> >
> > I just did a very quick search on Google for php + mixins, limited to
> 2007
> > or earlier (long before the current Trait implementation was born), and
> got
> > plenty of results lamenting the lack of support for horizontal reuse in
> PHP.
> >
> > See for yourself:
> >
> https://encrypted.google.com/search?q=php+%22horizontal+reuse%22=active=en=lnt=cdr%3A1%2Ccd_min%3A%2Ccd_max%3A12%2F31%2F2007=#safe=active=en=cdr:1%2Ccd_max:12%2F31%2F2007=php+mixins
> >
> > It's a common accusation of projects like this that time was spent on X
> > that should have been spent on Y, but that's nearly always a massive
> > over-simplification.
> >
> > Let's not spend too much time worrying if specific people are interested
> -
> > they may just be on holiday, or busy elsewhere, or just not have much to
> > say until someone assembles a few more details about the proposed
> feature.
> > Keep it constructive, lay out how you think the feature should look and
> > why, what questions are still open, and see what's needed to move it
> > forward.
> >
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
> Guilherme Blanco
> MSN: guilhermebla...@hotmail.com
> GTalk: guilhermeblanco
> Toronto - ON/Canada
>

Given that a lot of userland people have voting rights; I would suspect
that an annotations rfc would pass, provided it met the needs of these
users. As far as docblocks vs native goes - you've convinced me that native
would be best, previously I'd have been more in favour of adding a
getAnnotations method to ReflectionClass/Method/Property, to pull in
annotations from docblocks.

I'd like to see this goto a new RFC here are some questions though:

- Can annotations be applied to functions?
- Class constants?
- Should annotations be a special type eg annotation Foo{} or just a class?
- Do we want to add decorator support at the same time? (
http://thecodeship.com/patterns/guide-to-python-function-decorators/)

Re: [PHP-DEV] Re: Scalar Type Declaration Syntax Weirdness

[Chris Riley]

On 24 November 2015 at 17:16, Andrea Faulds  wrote:

> Hi Stas,
>
> Stanislav Malyshev wrote:
>
>> Hi!
>>
>>>>>function a(\int $i) {}

Is it intentional that the \ in front of the "int" is allowed? IMHO,
 this
confusing notation must not be allowed.

>>>
>>> This is weird and I'd consider it a bug. You can't do \array or
>>> \callable, and if I saw \int, I'd think it meant a class of that name
>>> rather than a scalar type.
>>>
>>
>> I would assume \int means class named "int", as opposed to "int" type.
>>
>
> That's also what I'd expect. However, "int" is not allowed as a class name
> in PHP 7. And unfortunately what the code Sebastian posted sctually does is
> act as an integer type hint, not as a class type hint.
>
> Can this be fixed for 7.0.0?
>>>
>>
>> I don't think this would be a good idea. We're in the final stretch of
>> release cycle, and should not do any non-urgent fixes. This does not
>> look urgent. It can wait for 7.0.1.
>>
>
> It can't wait for 7.0.1, because banning this would be a
> backwards-compatibility break with 7.0.0. We have to fix it in 7.0.0 or not
> fix it ever.
>
> Thanks.
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Could we not just document it as \int is not allowed and throws a fatal
error. Then we'd just be fixing a bug in documented behaviour.

~C

Re: [PHP-DEV] INDRECT in arrays causes count() to become unpredictable

[Chris Riley]

On 23 November 2015 at 09:08, Rasmus Lerdorf  wrote:

> On 11/23/2015 09:49 AM, Phil Sturgeon wrote:
> > The "There will always be bugs" argument is a strawman, nobody is
> > saying wait until it's perfect.
> >
> > People in this thread are consistently conflating "there will always
> > be bugs" with "lets just ignore this bug which is 'around critical'
> > and crack on because yolo."
>
> You seem to be confused Phil. Nobody is arguing that this bug shouldn't
> be fixed. The question is all about how severe it is and whether it
> should trigger another release candidate.
>
> -Rasmus
>
>
>
Am I missing something here? We found a bug, it was fixed, so if we tag .0
right now, that bug wouldn't be in .0? Not sure I see the issue here?

~C

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On 17 November 2015 at 11:04, Rowan Collins  wrote:

> Hi Andrea,
>
> Andrea Faulds wrote on 17/11/2015 01:47:
>
>> Larry Garfield wrote:
>>
>>> The "everything in the constructor" is the problem.  That results in,
>>> essentially, an obscenely long function call that just happens to be
>>> named __construct().  If I wanted something that obscure and hard to
>>> work with I'd just use anonymous arrays. :-)
>>>
>>
>> Huh?
>>
>> "with" methods and __construct are not exclusive. In fact, you could have
>> a private constructor and only have "with" methods. Only allowing
>> assignment to properties in the constructor doesn't prevent having a nice
>> API: have your methods call the constructor.
>>
>> I don't see what you're getting at here.
>>
>>
> Making the "with" methods wrap the constructor tidies the public API, but
> that (private) constructor needs to be just as complex as Larry said
> earlier - you've got to manually extract all the properties of one
> instance, and pass them as parameters to the other. Or, you could copy them
> one by one inside the body of the constructor, which comes to the same
> thing - lots of boilerplate.
>
> If you look at the PSR-7 implementation I linked to earlier [1], there's
> no such boilerplate, just a single call to "clone $this", and PHP does it
> all for you. But that doesn't work with a simplistic definition of
> immutable like "mutable in constructor" or "mutable until non-null"; you
> need to be able to "freeze" an instance once you've set it up, or have
> privileged (private) methods which are allowed to mutate the properties.
>
> [1] https://github.com/guzzle/psr7/blob/master/src/Request.php#L101
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Could clone take an array parameter of immutable property overrides?

$copied = clone ($immutable, ['foo' => 'bar']);

[PHP-DEV] Immutable modifier

[Chris Riley]

Hi,

There has been a lot of interest recently (eg psr-7) in immutable data. I'm
considering putting an RFC together to add language support for immutables:

immutable class Foo {
public $bar;
public function __construct($bar) {
$this->bar = $bar;
}
}

Immutable on a class declaration makes all (maybe only public?) properties
of the class immutable after construct; assigning to a property would
result in a Fatal error.

class Foo {
public $bar;
immutable public $baz;
}

Immutable on a property makes the property immutable once it takes on a
none null value. Attempts to modify the property after this results in a
fatal error.

Any thoughts?
~C

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On 16 November 2015 at 09:24, Daniel Persson <mailto.wo...@gmail.com> wrote:

> Any differance from the final keyword?
>
> http://php.net/manual/en/language.oop5.final.php
>
> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley <t.carn...@gmail.com> wrote:
>
>> Hi,
>>
>> There has been a lot of interest recently (eg psr-7) in immutable data.
>> I'm
>> considering putting an RFC together to add language support for
>> immutables:
>>
>> immutable class Foo {
>> public $bar;
>> public function __construct($bar) {
>> $this->bar = $bar;
>> }
>> }
>>
>> Immutable on a class declaration makes all (maybe only public?) properties
>> of the class immutable after construct; assigning to a property would
>> result in a Fatal error.
>>
>> class Foo {
>> public $bar;
>> immutable public $baz;
>> }
>>
>> Immutable on a property makes the property immutable once it takes on a
>> none null value. Attempts to modify the property after this results in a
>> fatal error.
>>
>> Any thoughts?
>> ~C
>>
>
>
Yes, final prevents child classes from overriding a method or from
extending a class entirely, this is a compile time constraint. Immutable
prevents data modifications and as such is a run time constraint.

~C

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On 16 November 2015 at 09:33, Lorenzo Fontana <fontanalor...@gmail.com>
wrote:

> I really like the concept of immutability, but I think that it should be
> applicable at  instance level rather than declaration.
>
> I would also prefer another keyword than immutable.
>
> Final does not make the properties immutable, it makes the class not
> extensible.
> On Nov 16, 2015 10:24, "Daniel Persson" <mailto.wo...@gmail.com> wrote:
>
>> Any differance from the final keyword?
>>
>> http://php.net/manual/en/language.oop5.final.php
>>
>> On Mon, Nov 16, 2015 at 10:15 AM, Chris Riley <t.carn...@gmail.com>
>> wrote:
>>
>> > Hi,
>> >
>> > There has been a lot of interest recently (eg psr-7) in immutable data.
>> I'm
>> > considering putting an RFC together to add language support for
>> immutables:
>> >
>> > immutable class Foo {
>> > public $bar;
>> > public function __construct($bar) {
>> > $this->bar = $bar;
>> > }
>> > }
>> >
>> > Immutable on a class declaration makes all (maybe only public?)
>> properties
>> > of the class immutable after construct; assigning to a property would
>> > result in a Fatal error.
>> >
>> > class Foo {
>> > public $bar;
>> > immutable public $baz;
>> > }
>> >
>> > Immutable on a property makes the property immutable once it takes on a
>> > none null value. Attempts to modify the property after this results in a
>> > fatal error.
>> >
>> > Any thoughts?
>> > ~C
>> >
>>
>
What instance level syntax would you propose?

$foo = new immutable bar();  ?

or

immutable $foo = new bar();

Gives less flexibility imo and less guarantees of correctness.

Consider the current user land implementation of immutable classes:

class Foo {
private $bar;
public function __construct($bar) {
$this->bar = $bar;
}

public function getBar() {
return $this->bar;
}
}

Is already done at declaration declaration based immutability is probably
more desirable.

What keyword would you suggest other than immutable?

~C

Re: [PHP-DEV] Immutable modifier

[Chris Riley]

On Tue, 17 Nov 2015, 02:07 Andrea Faulds <a...@ajf.me> wrote:

Hi,

Chris Riley wrote:
>
> There has been a lot of interest recently (eg psr-7) in immutable data.
I'm
> considering putting an RFC together to add language support for
immutables:
>

I wonder if immutable classes are really the right way to go. Immutable
reference types with manual copying are somewhat alien to PHP: instead,
the language has used copy-on-write mutable value types for arrays and
strings, and prior to PHP 5, objects.

Copy-on-write value types have all the benefits immutable types do. They
can't be mutated at a distance unless you make a reference to them,
trees made of them can be compared for equality with just ===, etc.

But they also have benefits that immutable types lack. They're easier to
work with, because you can directly mutate them like everyone's used to
doing: no messing around with withFooBar() and withoutFooBar(), you just
set foobar or remove it directly. And PHP handles the duplication of
objects for you implicitly, so there's far less code to write.

Unfortunately, PHP 5 got rid of PHP 4's value type objects and replaced
them with reference type objects. But we could always introduce a way to
get value type objects again. How about a `struct` keyword? It would be
equivalent to `class`, but produce a value type rather than a reference
type.

Any thoughts?

Thanks.
--
Andrea Faulds
http:// <http://ajf.me/>ajf.me/ <http://ajf.me/>

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


My main motivation for this was for event objects when doing event sourcing
- they are by definition unchangeable after creation. That said,
considering the wider use case there does seem to be a need to emulate the
with* functions.

One option would be to hide the messy constructor call within user defined
methods, but that would add a lot of boilerplate - something I was wanting
to reduce not increase.

I can't think of a clean easy way to add with* functionality at a language
level without even more magic (parameter skipping?)

As for setter injection - my initial proposal would support that - a
property declared immutable allows itself to be set - once.

If someone can give my wiki account rfc karma I can write this up so far
too help focus discussion.

~C

Re: [PHP-DEV] [VOTE] Void Return Type RFC

[Chris Riley]

Hi,

I'm still not sure why we are using void as the return type and not null.
Null matches behaviour, void just adds another keyword without value.

~C

On 30 October 2015 at 04:33, Rasmus Lerdorf  wrote:

> On 10/29/2015 08:55 PM, Stanislav Malyshev wrote:
> > Hi!
> >
> >> "void" or "null" as return type would give a 100% guarantee that every
> possible
> >> implementation of a given interface won't return any random value. Then
> it would
> >> make no difference if the returned value is being used or not, as it
> >> would always
> >> be null.
> >>
> >> So, it obviously solves the problem presented. There's not much to
> dismiss here.
> >
> > That's what I am having issue with. I don't see the case where such
> > guarantee is useful. If you're not using the return value, why do you
> > care if it's always null or sometimes null and sometimes baloney
> > sandwich? If you need always null, you have it: null. You don't need to
> > use return value of a function for it.
>
> I agree with you Stas, but I still voted yes on this RFC as I don't see
> the harm in having it. It is more of a hint for the compiler/static
> analyzers for them to spew warnings/errors than it is a useful feature
> at runtime. Enough people consider it a missing check mark on the
> feature list for it to be added.
>
> -Rasmus
>
>

Re: [PHP-DEV] Password_hash salt generation refactor

[Chris Riley]

On 19 October 2015 at 16:22, Tom Worster  wrote:

> On 10/18/15 7:39 PM, Ángel González wrote:
>
>> Korvin wrote:
>>
>>> +1 for 7.0.x security patch release, best effort sounds scary.
>>>
>> This is a salt. It doesn't need to be cryptographically secure. Using
>> php_rand()
>> there should pose no problem.
>> I would actually include that into the patch (move old lines 154-156
>> into the
>> FAILURE if).
>>
>
> A password salt needs to be unique. It does not need to be drawn from a
> CSPRNG but that is one of the few ways we can be reasonably confident of
> uniqueness (since, as usual, we assume the platform RNG is properly seeded).
>


A password salt should not be predictable, allowing a salt to potentially
become predictable is a bad idea. Solution is to use a CSPRNG for
generation of salts.

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 14 October 2015 at 22:52, Andrea Faulds  wrote:

> Good evening,
>
> I'm reviving my Void Return Type RFC, this time for PHP 7.1:
>
> https://wiki.php.net/rfc/void_return_type
>
> Please read it and tell me your thoughts!
>
> Thanks.
>
> P.S. As it so (fatefully?) happens, I originally introduced this on 14th
> February, and it's now 14th October, so it's been exactly 8 months!
>
> --
> Andrea Faulds
> http://ajf.me/
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Hi,

Semantically, I don't believe that there is sufficient difference between
"returns no value" and "returns a value which has been defined as having no
value" for us to care about it. The main difference you get between return
type of null and a return type of void seems to be some extra fatal errors,
for a developer there seems little value.

>From a user confusion point of view; PHP currently considers return; and
return null; to be equivalent (in fact some code style checkers will
replace one with the other) If (and only if) a function has a return type
of void these two statements are no longer equivalent - one is a fatal
error one is not. For any other return type specification, return null; and
return; would behave the same. This in itself would be enough for me to be
against adding a return type of void.

(also could someone enable my wiki acc: carnage; sent an email ~a week ago
and haven't heard back yet :()

~C

Re: [PHP-DEV] [RFC] Void Return Type (v0.2, reöpening)

[Chris Riley]

On 15 October 2015 at 16:32, Andrea Faulds  wrote:


> In a sense, what this RFC offers might be called a compromise. It enforces
> the rules of `void` within the function, but at the end of the day the
> caller still gets a null out of it since that's what PHP's always done.
>
>
>
If this truly is the case, then all you get over hinting void as the return
type instead of null is a fatal error for return null; Sure you can argue
for capturing intent but realistically the difference in intent between
'returns no value' and 'does not return a value' is something for
philosophers to argue over not programmers. ;)

[PHP-DEV] Add Scrypt support to password_hash

[Chris Riley]

We already have a pecl extension for adding scrypt to php, however I think
it would be worth while to add it as an additional option to password_hash.
We would of cause leave Bcrypt as the default option.

Any thoughts on this?

Chris