On 05/03/2016 03:50, Stephen Coakley wrote:
I'm not entirely sure about what you mean. On my system,
create_function returns something like '\x00lambda_1'. Do you mean
that users are guessing such a string in order to use it? Sounds like
the smelliest of code smells.
Maybe not constructing i
On Fri, 2016-03-04 at 21:50 -0600, Stephen Coakley wrote:
> Sounds like the smelliest of
> code smells.
Considering what I've seen (and in some cases done myself to outsmart my
later self) I wouldn't be surprised if some did. :-)
We can't imagine all the creativity of PHP users,
johannes
--
"Stephen Coakley" wrote in message
news:db.f0.25279.8c0d9...@pb1.pair.com...
On 02/18/2016 06:41 AM, Nikita Popov wrote:
Hi internals!
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'm using this RFC to collect various deprecations targeting P
On 03/04/2016 03:49 PM, Johannes Schlüter wrote:
On Fri, 2016-03-04 at 12:29 -0600, Stephen Coakley wrote:
Not a complete polyfill, since $newfunc is a closure and not a string,
so you cannot print out the function name. I have no idea if any code
relies on the lambda itself being a string thoug
On Fri, 2016-03-04 at 12:29 -0600, Stephen Coakley wrote:
> Not a complete polyfill, since $newfunc is a closure and not a string,
> so you cannot print out the function name. I have no idea if any code
> relies on the lambda itself being a string though.
This has impact on a few things, i.e. Re
On 03/04/2016 07:53 AM, Johannes Schlüter wrote:
On Thu, 2016-02-18 at 19:57 +, Andrea Faulds wrote:
I've actually used create_function on occasion for programmatically
generating functions (in particular to create a function for each PHP
operator), but it's trivially polyfillable, and it'd
On 02/18/2016 06:41 AM, Nikita Popov wrote:
Hi internals!
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'm using this RFC to collect various deprecations targeting PHP 7.1, as
having individual RFCs for these is too much management overhead. Eac
On Thu, 2016-02-18 at 19:57 +, Andrea Faulds wrote:
> I've actually used create_function on occasion for programmatically
> generating functions (in particular to create a function for each PHP
> operator), but it's trivially polyfillable, and it'd be better if
> people
> were implementing i
Hi Andrea,
On Thu, Feb 25, 2016 at 10:00 AM, Andrea Faulds wrote:
> Andrea Faulds wrote:
>>
>> Hi Yasuo,
>>
>> Yasuo Ohgaki wrote:
>>>
>>> This discussion is related to
>>>
>>> https://wiki.php.net/rfc/precise_float_value
>>>
>>> If you have comment on this, I appreciate it.
>>> Please search old
Hi again,
Andrea Faulds wrote:
Hi Yasuo,
Yasuo Ohgaki wrote:
This discussion is related to
https://wiki.php.net/rfc/precise_float_value
If you have comment on this, I appreciate it.
Please search old thread for discussions.
I'll start final RFC discussion for this when session RFC is finishe
On 2/24/2016 2:11 AM, Andrea Faulds wrote:
> Furthermore, if PHP developers find floating-point confusing and are
> genuinely surprised that 0.1 cannot be represented in binary exactly,
> then perhaps they should go and learn about what floating-point numbers
> do, rather than naïvely continuing on
On 24/02/16 01:11, Andrea Faulds wrote:
> Furthermore, if PHP developers find floating-point confusing and are
> genuinely surprised that 0.1 cannot be represented in binary exactly,
> then perhaps they should go and learn about what floating-point numbers
> do, rather than naïvely continuing on th
Hi,
Andrea Faulds wrote:
$ php -r 'var_dump(1.02, 1.01, 1.01
=== 1.02);'
float(1)
float(1)
bool(true)
I missed this when proof-reading. The output is actually:
php -r 'var_dump(1.02, 1.01, 1.01
=== 1.
Hi Yasuo,
Yasuo Ohgaki wrote:
This discussion is related to
https://wiki.php.net/rfc/precise_float_value
If you have comment on this, I appreciate it.
Please search old thread for discussions.
I'll start final RFC discussion for this when session RFC is finished.
Thank you for bringing that
Hi,
On Wed, Feb 24, 2016 at 9:48 AM, Stanislav Malyshev wrote:
>> foot, by discarding possibly important information when serialising - an
>> operation that's supposed to perfectly reproduce a value!
>
> I'm not sure this is correct. Also, for values that are not exactly
> representable in binary
Hi,
On Wed, Feb 24, 2016 at 11:37 AM, Net Mo wrote:
> I'd also deprecate anything related to passing the session id in query
> strings in ext/session and have it only working with cookies.
>
> session.use_cookies
> session.use_only_cookies
> url_rewriter.tags
> and possibly also arg_separator.* i
I'd also deprecate anything related to passing the session id in query
strings in ext/session and have it only working with cookies.
session.use_cookies
session.use_only_cookies
url_rewriter.tags
and possibly also arg_separator.* if related
Hi Stas,
Stanislav Malyshev wrote:
Hi!
foot, by discarding possibly important information when serialising - an
operation that's supposed to perfectly reproduce a value!
I'm not sure this is correct. Also, for values that are not exactly
representable in binary, I'm not sure you want to see
Hi!
> foot, by discarding possibly important information when serialising - an
> operation that's supposed to perfectly reproduce a value!
I'm not sure this is correct. Also, for values that are not exactly
representable in binary, I'm not sure you want to see
0.155511151231257827
Hi Nikita,
Nikita Popov wrote:
This RFC is incomplete -- I'm posting it now so people can suggest other
things that should be deprecated. I expect it to grow over time and don't
plan to vote on it in the immediate future.
I think this would be a good opportunity to look at our existing php.ini
Hi Zeev,
Zeev Suraski wrote:
On 18 בפבר׳ 2016, at 21:58, Andrea Faulds wrote:
Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid of
hebrev() and hebrevc()? It feels out-of-place to have a poorly-documented
standard library function specifically for converting bet
Hi!
>> Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid
>> of
I must note that I think this drive to "get rid of" functions that does
not stand in anybody's way (as opposed to the case of __autoload which
is incompatible with superior stackable autoloader solution) is
> On 18 בפבר׳ 2016, at 21:58, Andrea Faulds wrote:
>
>
> Hmm. Well, if we're doing mass deprecations, maybe we should finally get rid
> of hebrev() and hebrevc()? It feels out-of-place to have a poorly-documented
> standard library function specifically for converting between two different
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2/18/2016 8:57 PM, Andrea Faulds wrote:
>
> Nikita Popov wrote:
>> https://wiki.php.net/rfc/deprecations_php_7_1
>
> I've actually used create_function on occasion for
> programmatically generating functions (in particular to create a
> function
Hi Nikita,
Nikita Popov wrote:
I've created a bulk-deprecation RFC for PHP 7.1:
https://wiki.php.net/rfc/deprecations_php_7_1
I'd be fine with getting rid of all of the ones suggested so far
(__autoload, $php_errormsg, create_function, rand/srand).
I've actually used create_function on occa
25 matches
Mail list logo
