Hi, Benjamin,
I think Nikita's suggestion is suitable for these purposes:
https://github.com/php/php-rfcs.
At the moment this is an experimental repository, but in this case, it will be
quite possible to get feedback from the community: e.g.,
https://github.com/php/php-rfcs/pull/1.
wbr,
Serge
Hey Twosee,
Thanks for following up!
> checkLiveness() is not cost-free, it will also cause redundant system
call overhead, In fact, it has been heavily abused. I noticed that many PHP
network programming implementations do not care about the overhead of
system calls, such as constantly using rec
>
> You're asking for useless, no-effort feedback in the form of votes
> from people who have no actual involvement in the ongoing development
> or maintenance of the project, so that's what I gave you.
I'm surprised by these strong feelings. As a contributor and maintainer of
several open source
On Wed, Aug 19, 2020 at 3:35 PM Benjamin Morel wrote:
>
> Hi Paul!
>
> I'm writing off list to avoid polluting the thread too much.
I'm writing on list because it's weird that you call this pollution.
> Could you please care to explain your negative reaction to this proposal?
>
> Kind regards,
>
> On Aug 19, 2020, at 17:33, Ben Ramsey wrote:
>
>> On Aug 19, 2020, at 17:19, Benjamin Morel wrote:
>>
>>> There’s nothing stopping anyone from doing this right now. :-)
>>
>> Actually there is: without a link to the poll in the RFC itself, the poll
>> would probably not get enough visibilit
> On Aug 19, 2020, at 17:19, Benjamin Morel wrote:
>
>> There’s nothing stopping anyone from doing this right now. :-)
>
> Actually there is: without a link to the poll in the RFC itself, the poll
> would probably not get enough visibility to be useful.
I don’t think the RFC should include a
-1
On Wed, Aug 19, 2020 at 2:28 PM Benjamin Morel wrote:
>
> Hi internals,
>
> The heated debate about attribute syntax made me think once again that it
> would be valuable to get feedback in the form of votes from the community,
> not just from core developers, on RFCs under discussion.
>
> Unde
Thank you for your feedback, Ben & Stanislav.
*Ben:*
It’s all fairly transparent, and if non-voting members want to provide
> input, they have various ways to do so (e.g., posting here, giving
> feedback to someone who is active here, etc.).
While this is true, I'm afraid the opportunities to p
Hi!
> Understandably, the RFC voting process needs to be restricted to carefully
> selected people, mostly core developers. But the fact is, this process is a
> bit elitist, and fails to represent the community as a whole. A recent
PHP development is not a representative democracy. There's no
req
> On Aug 19, 2020, at 16:27, Benjamin Morel wrote:
>
> Hi internals,
>
> The heated debate about attribute syntax made me think once again that it
> would be valuable to get feedback in the form of votes from the community,
> not just from core developers, on RFCs under discussion.
>
> Understa
Hi internals,
The heated debate about attribute syntax made me think once again that it
would be valuable to get feedback in the form of votes from the community,
not just from core developers, on RFCs under discussion.
Understandably, the RFC voting process needs to be restricted to carefully
se
On Wed, Aug 19, 2020 at 11:09 AM Benjamin Eberlei wrote:
> I wanted to clarify that this is the **restarted* vote on Shorter
> Attribute Syntax Change, that means all votes cast between August
> 11th and 15th have been reset.
In case anyone wants to view the in-progress STV vote results, I took
I wanted to clarify that this is the **restarted* vote on Shorter Attribute
Syntax Change, that means all votes cast between August 11th and 15th have
been reset.
On Wed, Aug 19, 2020 at 12:50 PM Benjamin Eberlei
wrote:
> Hello everyone,
>
> We have started the vote on "Shorter Attributes Syntax
Hi Andreas,
On 19/08/2020 11:01, Andreas Leathley wrote:
> I mentioned the benefits of @{} in an email to this list on Monday, with
> the proposal to have both @@ and @{} as attribute syntax, so both camps
> could have their syntax (one with delimiters, one without) with minimal
Please, one and o
Hi Benjamin,
Thank you again for putting in the effort to update the RFC and
address most of the arguments brought up on list.
I would encourage everyone to read through the complete RFC before
voting, particularly the sections on BC breaks and forward
compatibility pros/cons. Top link:
https://w
Hello everyone,
We have started the vote on "Shorter Attributes Syntax Change" RFC to
decide one last time on what syntax to choose for the Attributes feature.
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
On Wed, 19 Aug 2020 at 09:46, Jordi Boggiano wrote:
> Just to mention something here in a bit more depth because it is easy to
> overlook in the RFC if you have looked at it a lot.
>
> In "Potential Future Benefits of Enclosed Delimiter Syntax" there is an
> addition of an example using an attrib
On 19.08.20 11:12, Benjamin Eberlei wrote:
With the choice being @@ or @{} - nothing would stop someone (not me ;-))
to make an RFC for 8.1 or later proposing to add a second syntax.
Sure. If @@ would end up winning again (who knows at this point), at
least one positive thing is that @{} could b
On Wed, Aug 19, 2020 at 11:13 AM Michael Voříšek - ČVUT FEL <
voris...@fel.cvut.cz> wrote:
> Please add discussion about merge conflicts. Any inline grouped
> attribute syntax needs a manual conflict resolution.
>
> With ungrouped syntax, I expect recommended CS to be one attribute per
> line.
>
On Wed, Aug 19, 2020 at 11:01 AM Andreas Leathley
wrote:
> On 19.08.20 10:47, Benjamin Eberlei wrote:
> > One last change that I didn't see yesterday as it was on Github and not
> > this list is the addition of another syntax proposal @{} with the same
> > benefits as @[], a little more snowflake
Please add discussion about merge conflicts. Any inline grouped
attribute syntax needs a manual conflict resolution.
With ungrouped syntax, I expect recommended CS to be one attribute per
line.
If this should be the case also for grouped syntax, then it not +1
character, but +2 new lines per
On 19.08.20 10:47, Benjamin Eberlei wrote:
One last change that I didn't see yesterday as it was on Github and not
this list is the addition of another syntax proposal @{} with the same
benefits as @[], a little more snowflake than compared to other languages,
but without the BC Break.
I mentio
On Tue, Aug 18, 2020 at 8:00 PM Benjamin Eberlei
wrote:
>
>
> On Tue, Aug 4, 2020 at 3:46 PM Derick Rethans wrote:
>
>> Hi,
>>
>> Out of Banjamin's suggestion[1], I've updated the Shorter Attribute
>> Syntax Change RFC to reflect that process:
>>
>> https://wiki.php.net/rfc/shorter_attribute_syn
Hi,
On 18/08/2020 20:00, Benjamin Eberlei wrote:
https://wiki.php.net/rfc/shorter_attribute_syntax_change
I have updated the RFC one last time with as much of the feedback as
possible:
- a section about comparing to complexity of type definitions
- removal of the machine reading section as to
24 matches
Mail list logo
