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

[Levi Morrison via internals]

It is my opinion that voting "no" should not require any more effort
than voting "yes". Voting "no" is just as reasonable as voting "yes".
We do not need to justify our opinion.

The burden of documenting the historical reasons for "no" should be
placed on the RFC authors, not the voters.

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

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

[Jakob Givoni]

On Wed, Mar 18, 2020 at 7:15 PM Mark Randall  wrote:
> Well, they shouldn't be casting a vote in the first place.
Hear! Hear!

Ok, I don't mean to be harsh, but rather to demonstrate a way that you can
express agreement with something someone else has said without repeating
it.
Maybe if more voters participated in discussions in this simple way, asking for
voting reasons post hoc would not come up time and time again...

Or to vary it:
- Ditto
- I agree
- True
- What (s)he said

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

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

[Mark Randall]

On 18/03/2020 23:22, Kalle Sommer Nielsen wrote:

I am not gonna personally answer a survey everytime I vote against a
feature. This is why we have a discussion period to raise issues, of
course not everyone will raise all their concerns to each and every
RFC (me included, take the annotation RFCS posted over the years, they
are awesome but the one thing I dislike is the syntax). I doubt
everyone have time to go in details and understand to the teeth what
each and every feature does. 


If a person doesn't have the time or inclination to read into the 
details of an RFC, and also doesn't have time or inclination to engage 
in discussion about it, and also doesn't have the time or inclination to 
give even the briefest of justification about why they are casting their 
vote a particular way to help inform future discussion...


Well, they shouldn't be casting a vote in the first place.

That's not to suggest everyone should need to be able to analyse the 
patch line by line, but if a person is cleary *that* disengaged then IMO 
they should do the honourable thing and refrain from voting.


MR.

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

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

[Kalle Sommer Nielsen]

Den man. 16. mar. 2020 kl. 20.29 skrev Mike Schinkel :
>
> Hi all,
>
> Seeing people referencing former RFCs that failed when someone brings up an 
> RFC (which is a good thing to reference, BTW) I am finally compelled to 
> comment in hope there would be will to improve it.
>
> When court justices rule on important decisions they write opinions, or join 
> with the majority or minority opinion. That way judges and others in the 
> future can know why things were decided a certain way.
>
> However in PHP we have no way of knowing why people voted against a proposal 
> except maybe for those very few who commented negatively on the mailing list. 
> Which is far from concise and frequently not conclusive.
>
> It is a real shame that the PHP voting process has no way to capture a 
> concise description of why people voted against an RFC.  A "No" vote could 
> mean any of the following, or something completely different, and their 
> reasons are really important when it comes to future consideration of the 
> same issue:
>
> 1. I hate the idea and never want to see it in PHP
> 2. I'm okay with the idea but
> a. I have a small issue with "x"
> b. I have a big issue with "y"
> c. I prefer to see it implemented using "z" approach instead
> 3. I love the idea but
> a. Can't support it given "x"
> b. I want it to be implement using "y" approach instead
> 4. We can't do this until we do "x" first
> 5. We should do "x" instead
> 6. Or who knows what other reason?
>
> Would it be possible to add a feature when voting were people either need to 
> type in a one to two sentence reason why they voted "no" on a proposal OR 
> select from the reasons that others have already given when voting down the 
> specific RFC?
>
> If we had that we could list the reasons and the number of votes that choose 
> those reasons on the RFC for historical purposes.

I am not gonna personally answer a survey everytime I vote against a
feature. This is why we have a discussion period to raise issues, of
course not everyone will raise all their concerns to each and every
RFC (me included, take the annotation RFCS posted over the years, they
are awesome but the one thing I dislike is the syntax). I doubt
everyone have time to go in details and understand to the teeth what
each and every feature does. I instead recommend that you look at Dan
Ackroyd's repository which he linked in his reply.

Similar to him, I'm also fairly against the development of such a feature.

-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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

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

[Christoph M. Becker]

On 17.03.2020 at 20:33, Mike Schinkel wrote:

>> On Mar 17, 2020, at 4:44 AM, Christoph M. Becker  wrote:
>>
>> On 17.03.2020 at 09:26, Nikita Popov wrote:
>>
>>> On Mon, Mar 16, 2020 at 8:09 PM Jakob Givoni  wrote:
>>>
 On Mon, Mar 16, 2020 at 1:29 PM Mike Schinkel  wrote:
> If we had that we could list the reasons and the number of votes that
 choose those reasons on the RFC for historical purposes.

 Thanks Mike, exactly what I was thinking when I started writing RFC:
 COPA (https://wiki.php.net/rfc/compact-object-property-assignment)!

 As you can see in my "Voting" section, I had the idea to capture
 reasons for no-votes, to document it in the outcome of the RFC, should
 it fail.
 It would have saved my research quite a bit if I had had the no-vote
 reasons for the RFCs I reference at the bottom.

 +1 on the idea from me!

>>>
>>> FWIW this has been discussed a few times already, and I believe the
>>> consensus is: We're happy to have *optional* reasons for votes, if someone
>>> actually implements it.
>>>
>>> For the number of times someone has brought this up on list, there has been
>>> a distinct lack of volunteers for actually making it happen ;)
>>
>> If anybody wants to take a stab at this, patching the doodle plugin[1]
>> would be the way to go.
>>
>> [1]
>> 
>
> Ah, I see.  So set up https://github.com/php/web-wiki locally and I'd have 
> what I need?

It might work to install a plain DokuWiki, and to put the repo contents
on top.  Otherwise, see
.

--
Christoph M. Becker

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

Re: [PHP-DEV] [Discussion] Promoting declare failure notices to exceptions?

[Nikita Popov]

On Sat, Mar 14, 2020 at 9:20 PM Mark Randall  wrote:

> Greetings,
>
> I have created a PR that will throw exceptions when using define()
> with invalid types or when trying to redefine.
>
> Trying to redefine a constant or define a bad constant would throw a
> ValueError on the name parameter, trying to pass an unsupported type
> would give a TypeError on the value parameter.
>
> Normal promotions are fairly run of the mill, however for some utterly
> bizarre reason the existing behaviour is to print a notice and not a
> warning as with almost all other functions that are failing.
>
> Is there a good reason not to promote these to exceptions?
>
> https://github.com/php/php-src/pull/5265
>

This was previously discussed in the context of
https://wiki.php.net/rfc/constant_redefinition. Looking back at the thread,
it basically went "we should not break BC in a minor version, do it in PHP
8 instead".

Well, now we have PHP 8, so let's do it.

This is also the first step towards improving our optimization capabilities
in this area. It's not quite enough by itself (due to early binding related
issues), but it's a step in the right direction.

Regards,
Nikita

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

[Paul M. Jones]

Hi all,

With the name change from `ServerRequest` to `SapiRequest` (et al.), discussion 
appears to have waned again.

I believe all relevant questions have been answered and recorded at this point. 
Please review the updated RFC and implementation, and present any more 
questions/comments/concerns you may have.

Unless there are objections (or new substantive discussion) I plan to open 
voting tomorrow or Friday. 

Thanks to everyone who has participated so far!


-- 
Paul M. Jones
pmjo...@pmjones.io
http://paul-m-jones.com

Modernizing Legacy Applications in PHP
https://leanpub.com/mlaphp

Solving the N+1 Problem in PHP
https://leanpub.com/sn1php

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

Re: [PHP-DEV] [RFC] [VOTE] Immutable/final/readonly properties

[Larry Garfield]

On Tue, Mar 17, 2020, at 1:07 PM, Máté Kocsis wrote:

> At this point I'd like to repeat one of my previously mentioned arguments
> for the feature:
> if we have an immutable PSR-7 that is used all over the PHP ecosystem, and
> we also have
> lots of people who wish for more type-level strictness by using immutable
> DTOs or VOs,
> why don't we provide a proper way to achieve immutability? If there is such
> a need
> then I think we should react. Even more so, because the same feature is
> available in other
> languages where we usually copy from, so it wouldn't even be without
> precedents.
> (Just to be clear: I don't think that we have to copy everything from Java
> or C#. :) )

I don't have voting rights yet, but I would also vote no as is precisely 
because of the PSR-7 type case, along the same lines that Nicolas is arguing.

Currently, a PSR-7 implementation does something like this (assuming it were 
updated to typed properties):

class Response implements ResponseInterface {

  private int $statusCode;

  public function getStatusCode : string {
return $this->statusCode;
  }

  public function withStatusCode(int $code): self {
$new = clone($this):
$new->statusCode = $code;
 return $new;
  }
}

Now repeat that for about 10 different properties across 3 different objects, 
and sometimes with multiple variations on the with*() method.

Allowing the status code to be declared public-readonly would change it to this:

class Response implements ResponseInterface {

  public readonly int $statusCode;

  public function withStatusCode(int $code): self {
$new = new static(
  $code, 
  $this->headers, 
  $this->protocolVersion, 
  $this->body
 );
 return $new;
  }
}

And that's for Response, which is the simplest of the message objects in PSR-7.

That is, you get to skip the trivially easy method (a positive) in return for 
having a longer and more involved with*() method, which you already have more 
of to begin with (a negative), and for forcing you to have a constructor that 
takes every possible property (a negative).  

That is not a net win.

Thinking about it, Uri is possibly an even better example as it has 8 
properties:

class Uri implements UriInterface {

private string $scheme;

private string $authority;

private string $userInfo;

private string $host;

private int $port

private string $path;

private array $query;

private string $fragment;

// These methods could all go away, but they're the simple ones:

public function getScheme() {
return $this->scheme;
}

public function getAuthority();

public function getUserInfo();

public function getHost();

public function getPort();

public function getPath();

public function getQuery();

public function getFragment();

// Whereas these turn from this:

public function withScheme(string $scheme) {
  $new = clone($this);
  $new->scheme = $scheme;
  return $new;
}

// In this:

public function withScheme(string $scheme) {
  $new = static(
$scheme, 
$this->authority, 
$this->userInfo, 
$this->host, 
$this->port, 
$this->path, 
$this->query, 
$this->fragment
   );
  return $new;
}

   // And doing so for all of these methods, but slightly differently:

public function withUserInfo($user, $password = null);

public function withHost($host);

public function withPort($port);

public function withPath($path);

public function withQuery($query);

public function withFragment($fragment);
}

So switching it to use readonly properties as proposed here, would involve:

* More complex methods
* A mandatory 8 parameter constructor
* Avoiding the trivial methods in exchange for the mandatory methods being 
longer.

Honestly... that's not usable for value objects.  I love value objects, I love 
immutable values, and I would find this property useless in its current form.

Also, I just realized... properties cannot be defined in interfaces.  That 
means a PSR interface (or any other interface) could not require that they be 
defined, which means they cannot be made part of a contract.  That renders 
readonly properties as defined here unusable by FIG entirely.

Requiring that properties be typed to be readonly is fine with me.  But the way 
it renders cloning unusable for evolvable objects makes evolvable objects 
considerably harder to use and to standardize, not easier.

And this property co-existing with some other way of achieving the same goal 
(whether that's something like Nicolas's proposal or something entirely 
different) would only lead to confusion and people doing one, realizing they 
should have done the other, and having more BC breaks now in their own code.

I appreciate the work that Mate has put into this proposal, but as is I have to 
encourage people to vote no.

--Larry Garfield

--

Re: [PHP-DEV] RFC Karma

[Craig Francis]

Thanks Nikita.



On Wed, 18 Mar 2020 at 10:59, Nikita Popov  wrote:

> On Wed, Mar 18, 2020 at 11:52 AM Craig Francis 
> wrote:
>
>> Hi,
>>
>> I've created a Wiki account (craigfrancis), and I believe the next step is
>> to ask for RFC Karma.
>>
>> This is so I can write up about the suggested is_literal() function.
>>
>> https://news-web.php.net/php.internals/108977
>>
>> Craig
>>
>
> Hi Craig,
>
> I've granted you RFC karma.
>
> Nikita
>

[PHP-DEV] Re: RFC Karma

[Christoph M. Becker]

On 18.03.2020 at 11:51, Craig Francis wrote:

> I've created a Wiki account (craigfrancis), and I believe the next step is
> to ask for RFC Karma.
>
> This is so I can write up about the suggested is_literal() function.
>
> https://news-web.php.net/php.internals/108977

You should already have RFC karma.

--
Christoph M. Becker

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

Re: [PHP-DEV] RFC Karma

[Nikita Popov]

On Wed, Mar 18, 2020 at 11:52 AM Craig Francis 
wrote:

> Hi,
>
> I've created a Wiki account (craigfrancis), and I believe the next step is
> to ask for RFC Karma.
>
> This is so I can write up about the suggested is_literal() function.
>
> https://news-web.php.net/php.internals/108977
>
> Craig
>

Hi Craig,

I've granted you RFC karma.

Nikita

[PHP-DEV] RFC Karma

[Craig Francis]

Hi,

I've created a Wiki account (craigfrancis), and I believe the next step is
to ask for RFC Karma.

This is so I can write up about the suggested is_literal() function.

https://news-web.php.net/php.internals/108977

Craig