Hey everyone,
I'm asking for some RFC karma for wiki account nikita2206
in preparation of callable typehints RFC [0]
with Marcio, and some other RFCs in the future.
Thanks in advance \O/
[0] https://wiki.php.net/rfc/callable-types
--
PHP Internals - PHP Runtime Development Mailing List
To
On 9/2/15 5:34 PM, Rowan Collins wrote:> On 02/09/2015 20:44, Tom Worster
wrote:
>> In other words, ~> will end my career. Thanks :P
>
> I know this line is just hyperbole, but it does rather sum up the tone
> of the rest of your e-mail. I'm honestly not sure how you expect anyone
> to respond.
+1
He did most of the hard work for this particular RFC already,
so it would be great to give him permission to edit too.
2015-09-03 11:08 GMT-03:00 Nikita Nefedov :
> Hey everyone,
>
> I'm asking for some RFC karma for wiki account nikita2206
> in preparation of callable
Tom Worster wrote on 03/09/2015 15:46:
The unspoken rules of civility make some people suppress negative
reactions to the proposal. In this case it was even implied, as you point
out, that dissenting opinion is unwelcome. But I don't think such
constraints are entirely fair so I gave my opinion.
Pierre Joye in php.internals (Thu, 3 Sep 2015 18:40:06 +0700):
>On Sep 3, 2015 2:48 PM, "Jan Ehrhardt" wrote:
>>
>> Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200):
>> >I'd love to see this make it into PHP 7.0 if it's not too late? It's
>> >extremely trivial,
On Thu, Sep 3, 2015 at 12:48 AM, Rowan Collins wrote:
>
> So I would like to put forward for consideration these amendments to the
> proposal, in the spirit of compromise (in no particular order; numbers are
> just for reference in future discussion):
>
> Amendment 1.
Hi Scott
2015-09-03 6:14 GMT+02:00 Scott Arciszewski :
>
> Inspired by http://stackoverflow.com/a/12202218/2224584
>
> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
> statements off by default, and still allow developers to turn it on if
> they really want
Hi Stas,
On Thu, Sep 3, 2015 at 1:56 PM, Stanislav Malyshev wrote:
>> I see number of var_push_dtor() to fix unserialization.
>> var_push_dtor() or var_push_dtor_no_addref() is required always when
>> php_var_unserialize() is failed.
>> Am I correct?
>
> Not necessarily.
On Thu, Sep 3, 2015 at 4:08 AM, Kalle Sommer Nielsen wrote:
> Hi Scott
>
> 2015-09-03 6:14 GMT+02:00 Scott Arciszewski :
>>
>> Inspired by http://stackoverflow.com/a/12202218/2224584
>>
>> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
>>
On Thu, Sep 3, 2015 at 2:33 AM, Ferenc Kovacs wrote:
>
> 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ):
>>
>> Inspired by http://stackoverflow.com/a/12202218/2224584
>>
>> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
>> statements
2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ):
>
> Inspired by http://stackoverflow.com/a/12202218/2224584
>
> Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
> statements off by default, and still allow developers to turn it on if
> they really want
Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200):
>I'd love to see this make it into PHP 7.0 if it's not too late? It's
>extremely trivial, but whatever not that fussed :)
>
>PR is here: https://github.com/php/php-src/pull/1497
I applied the same patch to the sources of the almost
Den 2015-09-03 kl. 11:56, skrev Rowan Collins:
Pavel Kouřil wrote on 03/09/2015 07:32:
Amendment 2. Make the ~> operator non-associative
Why? Once you read documentation about how the operator works and what
it does, you will know it and writing the extra brackets seems
superfluos. And
Pavel Kouřil wrote on 03/09/2015 07:32:
I wouldn't mind the
mandatory ( ) around parameters, but at the same time I think that
it's an useless rule and makes the written code more "cluttered" (too
much ( and ) imho make the code less readable).
Bear in mind that under the current proposal, the
Pavel Kouřil wrote on 03/09/2015 07:32:
Amendment 2. Make the ~> operator non-associative
Why? Once you read documentation about how the operator works and what
it does, you will know it and writing the extra brackets seems
superfluos. And woudn't this complicate the parser even more? Also,
Dan Cryer wrote on 03/09/2015 11:40:
Out of interest, is there a technical reason you couldn't use an existing
token, such as => for this?
https://wiki.php.net/rfc/short_closures#symbol_choice
In particular, note that this is already valid code:
[$x => $x * 2]
(A one-element array, specifying
>
> I had this RFC in draft since some time, but delayed it due to all the
> ongoing PHP 7 discussions. Also we have no master branch to merge features
> in until 5.4 EOL. Thus I'm reviving this now.
>
> Time for the first RFC targeting PHP 7.1 (assuming PHP 8 isn't going to be
> the next version
Results for project php-src-nightly, build date 2015-09-03 11:56:02+03:00
commit: 49ee37d870a5eb607ad9a6d4be9b5fe547ff0949
revision_date: 2015-09-02 23:15:57-07:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
On Thu, Sep 3, 2015 at 8:33 AM, Ferenc Kovacs wrote:
>
> 2015. szept. 3. 6:14 ezt írta ("Scott Arciszewski" ):
> >
> > Inspired by http://stackoverflow.com/a/12202218/2224584
> >
> > Can we (in either PHP 7.0 or in PHP 7.1) turn emulated prepared
> >
On Sep 3, 2015 2:48 PM, "Jan Ehrhardt" wrote:
>
> Davey Shafik in php.internals (Wed, 2 Sep 2015 17:31:44 +1200):
> >I'd love to see this make it into PHP 7.0 if it's not too late? It's
> >extremely trivial, but whatever — not that fussed :)
> >
> >PR is here:
On 03/09/15 12:25, Ferenc Kovacs wrote:
>> Last time we discussed this it was Anthony who proposed the change and
>> > Rasmus shed some light on why did we have the emulation in the first place.
>> > We can have change the default but we should have an RFC clearly stating
>> > the impact (an
Hi all,
IEEE 754 double cannot express exact float values. That said,
float values expressed by json/serialize/var_export/echo/print
are not precise enough in many cases.
Issues:
- json_encode() uses EG(precision)=14 that truncates float values.
echo()/print()
does this as well.
- large
On Wed, Sep 2, 2015 at 3:48 PM, Rowan Collins wrote:
> Amendment 1. Only allow the single-expression form of the short syntax; full
> function bodies must be declared with the existing function(){ ... } syntax.
> This gives a clearer distinction between how the two
23 matches
Mail list logo