On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
> It's an alternative to the proposed Attributes RFC and the (2010)
> Annotations RFC.
>
> I'm attempting with this to de
> On 14/05/2016, at 4:16 AM, Sara Golemon wrote:
>
> On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>>> provide a mechanism for defining it on userspace functions)?
>>
>> That's right, except that, if we only consi
Love the simplicity of the RFC, but I can already see people doing terrible
things with it:
<< new DateTimeImmutable() >>
<< log(get_instance('logger')) >>
And other global-state related stuff.
TBH, I'd rather just allow a constant array (with constant expressions
only), and that would be good
Evening,
> This is why I defined the TPE RFC to scope that permission SOLELY to
the arguments section.
I get that, but it doesn't make enough of a difference, in my opinion.
> We can, and I'd settle for that as a first step, but as the RFC
states, it doesn't do justice to the "Agains
On Fri, May 13, 2016 at 1:56 PM, Joe Watkins wrote:
> Still, I regard editing someone else's work as poor form.
>
> Introducing a way to do that, and relying on social pressure to keep
> everyone in check is not a good long term plan ... sounds great, until
> someone actually does make an
Evening,
I like the idea that we should pay more attention to setting out
arguments, for and against.
Still, I regard editing someone else's work as poor form.
Introducing a way to do that, and relying on social pressure to keep
everyone in check is not a good long term plan ... soun
Hi!
> BUT, these Wikis have a history log. And if John Smith removes or
> maliciously modifies an argument I've introduced, I'll notice, and
> I'll be the first to ask for a public explanation of why he chose to
> do so. Maybe they were right to do so, maybe they weren't.
> Regardless, that'll p
On Fri, May 13, 2016 at 10:18 AM, François Laupretre wrote:
>> So we'd have to audit all 4k+ functions in the PHP runtime (and
>> provide a mechanism for defining it on userspace functions)?
>
> That's right, except that, if we only consider functions accepting more than
> 1 arg, we just need to c
On Fri, May 13, 2016 at 7:26 AM, François Laupretre wrote:
> Le 13/05/2016 à 15:30, Rowan Collins a écrit :
>>
>> If somebody adds something that is genuinely irrelevant (e.g. based on a
>> simple misunderstanding of the RFC) then somebody else (*anyobdy* else)
>> could remove it.
>>
>
> Maybe I a
Hi Sara,
Le 13/05/2016 à 00:41, Sara Golemon a écrit :
So we'd have to audit all 4k+ functions in the PHP runtime (and
provide a mechanism for defining it on userspace functions)?
That's right, except that, if we only consider functions accepting more
than 1 arg, we just need to check about 1
On 13/05/2016 15:26, François Laupretre wrote [not in quite this order,
I hope I haven't changed the meaning by grouping your sentences
differently]:
Le 13/05/2016 à 15:30, Rowan Collins a écrit :
If somebody adds something that is genuinely irrelevant (e.g. based on a
simple misunderstanding
Le 13/05/2016 à 15:30, Rowan Collins a écrit :
If somebody adds something that is genuinely irrelevant (e.g. based on a
simple misunderstanding of the RFC) then somebody else (*anyobdy* else)
could remove it.
Maybe I am not candid enough but do you imagine what it could become on
a controversi
On Fri, May 13, 2016 at 3:30 PM, Rowan Collins
wrote:
> On 13/05/2016 11:07, François Laupretre wrote:
>
>> Le 12/05/2016 à 19:33, Sara Golemon a écrit :
>>
>>> https://wiki.php.net/rfc/rfc.third-party-editing
>>>
>>> Let's make RFCs more useful before AND after voting!
>>>
>>> -Sara
>>>
>>>
>> A
On 13/05/2016 11:07, François Laupretre wrote:
Le 12/05/2016 à 19:33, Sara Golemon a écrit :
https://wiki.php.net/rfc/rfc.third-party-editing
Let's make RFCs more useful before AND after voting!
-Sara
As RFC author, what should I do with irrelevant arguments against my RFC
? Should I add a
On 05/13/2016 02:57 PM, Davey Shafik wrote:
> On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
>
>> Dear Internals,
>>
>> I'm announcing a simplified RFC for annotations:
>>
>> https://wiki.php.net/rfc/simple-annotations
>>
>> It's an alternative to the proposed Attributes RFC and the (201
On Fri, May 13, 2016 at 2:11 PM, Rasmus Schultz wrote:
> Dear Internals,
>
> I'm announcing a simplified RFC for annotations:
>
> https://wiki.php.net/rfc/simple-annotations
>
> It's an alternative to the proposed Attributes RFC and the (2010)
> Annotations RFC.
>
> I'm attempting with this to de
Dear Internals,
I'm announcing a simplified RFC for annotations:
https://wiki.php.net/rfc/simple-annotations
It's an alternative to the proposed Attributes RFC and the (2010)
Annotations RFC.
I'm attempting with this to describe a feature that is closer to the
language than what is proposed by
Results for project PHP master, build date 2016-05-13 06:28:56+03:00
commit: ccf18da
previous commit:8a7a913
revision date: 2016-05-13 01:40:15+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On Fri, May 13, 2016 at 2:33 AM, Sara Golemon wrote:
> https://wiki.php.net/rfc/rfc.third-party-editing
>
> Let's make RFCs more useful before AND after voting!
Sure. I'll adopt this from now on regardlessly.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Developme
Le 29/04/2016 23:31, Sara Golemon a écrit :
Voting has opened for https://wiki.php.net/rfc/octal.overload-checking
Vote YES to raise a compile time warning when octal values greater
than \377 are used.
Vote NO to continue ignoring the overflow.
Hi,
At AFUP, we would be +1 for the warning: it
Le 12/05/2016 à 19:33, Sara Golemon a écrit :
https://wiki.php.net/rfc/rfc.third-party-editing
Let's make RFCs more useful before AND after voting!
-Sara
As RFC author, what should I do with irrelevant arguments against my RFC
? Should I add a reply ? More generally, I don't like the idea t
21 matches
Mail list logo
