Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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. >>>

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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 ===

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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 >

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

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)

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

> 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

Re: [PHP-DEV] Re: [RFC] Deprecations for PHP 7.1

-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 >