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

[Rowan Collins]

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 it, but detecting it? I'm not sure why you'd 
*need* to tell the difference between a create_function "lambda" and a 
Closure instance, but somebody somehwere might have hacked it in.


Regards,

--
Rowan Collins
[IMSoP]


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Johannes Schlüter]

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




-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stephen Coakley]

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


This has impact on a few things, i.e. Reflection or users might guess
the name. Anyways: Take away: A polyfill won't be 100% identical.

However the typical use case should be around usort() or similar where
this doesn't matter.

johannes



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.


--
Stephen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Johannes Schlüter]

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. Reflection or users might guess
the name. Anyways: Take away: A polyfill won't be 100% identical.

However the typical use case should be around usort() or similar where
this doesn't matter.

johannes


signature.asc
Description: This is a digitally signed message part

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

[Stephen Coakley]

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 be better if
people
were implementing it themselves (and thus knowing it's based on
eval())
than using it directly without this knowledge.


Just as a detail: You can't create a 100% compatible polyfill to
create_function(). create_function() names functions starting with \0.
Functions starting with \0 are hidden from get_defined_functions() and
possibly other places.

php > echo sizeof(get_defined_functions()['user']);
0
php > create_function('', '');
php > echo sizeof(get_defined_functions()['user']);
0
php > eval('function foo() {}');
php > echo sizeof(get_defined_functions()['user']);
1

johannes



Good point. Another approach to a polyfill would be to use a closure then:

function create_function(string $args, string $code)
{
return eval("return function($args) { $code };");
}

$newfunc = create_function('$a,$b', 'return "ln($a) + ln($b) = " . 
log($a * $b);');

echo $newfunc(2, M_E) . "\n";

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.


--
Stephen

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Johannes Schlüter]

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 it themselves (and thus knowing it's based on
> eval()) 
> than using it directly without this knowledge.

Just as a detail: You can't create a 100% compatible polyfill to
create_function(). create_function() names functions starting with \0.
Functions starting with \0 are hidden from get_defined_functions() and
possibly other places.

php > echo sizeof(get_defined_functions()['user']);
0
php > create_function('', '');
php > echo sizeof(get_defined_functions()['user']);
0
php > eval('function foo() {}');
php > echo sizeof(get_defined_functions()['user']);
1

johannes


signature.asc
Description: This is a digitally signed message part

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

[Yasuo Ohgaki]

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 thread for discussions.
>>> I'll start final RFC discussion for this when session RFC is finished.
>>
>>
>> Thank you for bringing that RFC up again, it would improve this
>> situation somewhat. Particularly in that it would use the "0" precision
>> for zend_dtoa, which is the "shortest sequence of digits producing the
>> same value when converted back to a float" behaviour that I mentioned in
>> my email.
>>
>
> This article has a good explanation of the two different approaches:
>
> http://blog.reverberate.org/2016/02/06/floating-point-demystified-part2.html

Nice article!
Added URL to reference section of the RFC.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrea Faulds]

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


Thank you for bringing that RFC up again, it would improve this
situation somewhat. Particularly in that it would use the "0" precision
for zend_dtoa, which is the "shortest sequence of digits producing the
same value when converted back to a float" behaviour that I mentioned in
my email.



This article has a good explanation of the two different approaches:

http://blog.reverberate.org/2016/02/06/floating-point-demystified-part2.html


--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Fleshgrinder]

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 thinking they're decimals thanks
> to PHP lying to them! It is not the job of the language to try and hide
> that floats are imprecise from programmers.
> 

+1 for removing the options and on the RFC. I have to deal with float
comparisons and BIGINT being cast to (int) in PHP every day and people
simply do not get it. The language should be brutal when it comes to
these things and warn, throw exceptions, whatever. :P

-- 
Richard "Fleshgrinder" Fussenegger



signature.asc
Description: OpenPGP digital signature

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

[Lester Caine]

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 thinking they're decimals thanks
> to PHP lying to them! It is not the job of the language to try and hide
> that floats are imprecise from programmers.

This just about sums up my understanding on the differences between a
programmer and a software engineer. There are fundamental limits to each
of the different hardware platforms one is running code on, so
'assuming' that the answers you get are always the same simply proves
one still has to learn how to program. SQL addressed many of these
differences early on, and things like fractional currency fields being
managed as integers with a fixed fractional offsets ( NUMBER(8,3) )
which accurately record 'tenth of a cent' provide clean interfaces, but
all too often they get transferred into 'float' because it's 'easier to
handle'. That PHP makes some of these conversions transparently *IS* the
problem of the language, but often it's because the programmer is simply
ignorant of why the original methods were adopted?

BIGINT is an example of where there are different understandings of just
what a number is, and trying to add unlimited accuracy is not a
substitution to the fact that when accessed from a database a BIGINT is
simply a clean 64bit number. Float has the same limitations based on
just what hardware is providing it?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrea Faulds]

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.02);'

float(1)
float(1)
bool(false)

Which reflects the point I was trying to make (two numbers that are NOT 
exactly equal according to === are printed identically by var_dump()).


I made a mistake in my original email, sorry.

--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrea Faulds]

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 RFC up again, it would improve this 
situation somewhat. Particularly in that it would use the "0" precision 
for zend_dtoa, which is the "shortest sequence of digits producing the 
same value when converted back to a float" behaviour that I mentioned in 
my email.


--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Yasuo Ohgaki]

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, I'm not sure you want to see
> 0.155511151231257827021181583404541015625 instead of
> 0.1. You certainly don't want var_dump to print that by default - this
> would make display cluttred and have very high WTF factor - why I
> entered 0.1 and get this enormous snake of a number? PHP must be broken!
> Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
> want to see 8 or 7.99911182158029987476766109466552734375?
>
> In fact, when we represent 0.1 as 0.1 when serializing our outputting,
> we are not discarding information, on the contrary - we are preserving
> exactly the information that was given to us by user.
>
>> print floats to their full precision - including in var_dump(). This can
>> create unreasonable confusion when debugging (why are two numbers that
>> appear identical with var_dump() reported as inequal?), means
>
> You really think that displaying 8.2 - 0.2 as 8 is more confusing than
> displaying it as 7.99911182158029987476766109466552734375?
>
>> potentially important information is removed by default, and really
>> ought not to be a global setting anyway: if you want to format your
>> numbers with reduced precision, do so explicitly.
>
> That would mean optimizing for case that nobody wants, and de-optimizing
> case that pretty much everybody wants. Ask 100 people using PHP what
> they want as a result of 8.2 - 0.2 and count how many of them want to
> see full-precision monster of a number.
>
>> There might be others worth dealing with, too, these are just the first
>> three I thought of.
>
> I would very much advise not to mess with any options until we are
> definitely, 100%, without any doubt sure that nobody needs to use it for
> anything. Removing options earns us nothing in terms of functionality.
> If nobody uses them - ok, fine - drop them. If we need to remove them
> e.g. because component they address goes away or changes function in a
> way that makes it irrelevent - fine, drop them. But doing it just
> because very small number of people that we can engage in discussion on
> the list (and that's not going to ever change - PHP user community is
> vastly larger than people even reading this list, let alone actively
> participating in it) think it's not needed IMHO is a very wrong
> approach. Sometimes we have no choice but to take decisions with this
> incomplete knowledge - but here we have a perfectly good option of just
> leaving it alone. All other options should be weighted against it.

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.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Yasuo Ohgaki]

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.* if related

These settings are mandatory for session module to work correctly.

Regards,

--
Yasuo Ohgaki
yohg...@ohgaki.net

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrea Faulds]

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
0.155511151231257827021181583404541015625 instead of
0.1.


This assumes we would print an exact decimal representation, but that's 
far more than necessary. In order to get the same result when converted 
back to a float, we need at most 17 digits. In many cases we don't even 
need to show 17, because there are not that many digits in a 
full-precision decimal representation (e.g. 0.5). We could use less in 
many cases if PHP were to switch to the approach other languages use, 
where we output only the shortest sequence of digits producing the same 
value when converted back to a float (whereas currently we output in 
full precision, up to 17 significant figures).



You certainly don't want var_dump to print that by default - this
would make display cluttred and have very high WTF factor


Why would displaying at most three extra digits have a "high WTF factor"?


- why I
entered 0.1 and get this enormous snake of a number?

 PHP must be broken!

var_dump() is a debugging function. If it shows a value, it must 
represent it accurately. Otherwise:


$ php -r 'var_dump(1.02, 1.01, 1.01 
=== 1.02);'

float(1)
float(1)
bool(true)

Please explain to me why this is intuitive and reasonable behaviour for 
a debugging function.


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 thinking they're decimals thanks 
to PHP lying to them! It is not the job of the language to try and hide 
that floats are imprecise from programmers.



Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
want to see 8 or 7.99911182158029987476766109466552734375?


Let's look at what our contemporary programming languages do.

Python:

>>> 8.2 - 0.2
7.999

JavaScript:

8.2 - 0.2
7.999

That's much shorter than your suggestion.

Heck, let's look at what var_export() does:

$ php -r 'var_export(8.2 - 0.2);'
7.9991

Still a lot shorter.


In fact, when we represent 0.1 as 0.1 when serializing our outputting,


But we don't represent 0.1 as 0.1:

$ php -r 'var_export(0.1);'
0.10001


we are not discarding information, on the contrary - we are preserving
exactly the information that was given to us by user.


$ php -r 'var_dump(1.02);'
float(1)

That doesn't look very preserved to me.




print floats to their full precision - including in var_dump(). This can
create unreasonable confusion when debugging (why are two numbers that
appear identical with var_dump() reported as inequal?), means


You really think that displaying 8.2 - 0.2 as 8 is more confusing than
displaying it as 7.99911182158029987476766109466552734375?


It's more *honest*. If two values are different, they should not be 
displayed the same.


And, again, the result would not be that large:

$ php -r 'var_export(8.2 - 0.2);'
7.9991




potentially important information is removed by default, and really
ought not to be a global setting anyway: if you want to format your
numbers with reduced precision, do so explicitly.


That would mean optimizing for case that nobody wants, and de-optimizing
case that pretty much everybody wants.


Who wants to round numbers to the same precision in all situations, for 
all apps running on their server, for all code running within a given 
request, even in libraries?



Ask 100 people using PHP what
they want as a result of 8.2 - 0.2 and count how many of them want to
see full-precision monster of a number.


"7.9991" isn't that monstrous, and it could be even less so 
if PHP used a nicer float-to-string conversion approach.





There might be others worth dealing with, too, these are just the first
three I thought of.


I would very much advise not to mess with any options until we are
definitely, 100%, without any doubt sure that nobody needs to use it for
anything. Removing options earns us nothing in terms of functionality.
If nobody uses them - ok, fine - drop them. If we need to remove them
e.g. because component they address goes away or changes function in a
way that makes it irrelevent - fine, drop them. But doing it just
because very small number of people that we can engage in discussion on
the list (and that's not going to ever change - PHP user community is
vastly larger than people even reading this list, let alone actively
participating in it) think it's not needed IMHO is a very wrong
approach.


This might be a fine argument, but I'm not 

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

[Stanislav Malyshev]

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.155511151231257827021181583404541015625 instead of
0.1. You certainly don't want var_dump to print that by default - this
would make display cluttred and have very high WTF factor - why I
entered 0.1 and get this enormous snake of a number? PHP must be broken!
Moreover, when you do "$a = 8.2 - 0.2" and then print/send $a, do you
want to see 8 or 7.99911182158029987476766109466552734375?

In fact, when we represent 0.1 as 0.1 when serializing our outputting,
we are not discarding information, on the contrary - we are preserving
exactly the information that was given to us by user.

> print floats to their full precision - including in var_dump(). This can
> create unreasonable confusion when debugging (why are two numbers that
> appear identical with var_dump() reported as inequal?), means

You really think that displaying 8.2 - 0.2 as 8 is more confusing than
displaying it as 7.99911182158029987476766109466552734375?

> potentially important information is removed by default, and really
> ought not to be a global setting anyway: if you want to format your
> numbers with reduced precision, do so explicitly.

That would mean optimizing for case that nobody wants, and de-optimizing
case that pretty much everybody wants. Ask 100 people using PHP what
they want as a result of 8.2 - 0.2 and count how many of them want to
see full-precision monster of a number.

> There might be others worth dealing with, too, these are just the first
> three I thought of.

I would very much advise not to mess with any options until we are
definitely, 100%, without any doubt sure that nobody needs to use it for
anything. Removing options earns us nothing in terms of functionality.
If nobody uses them - ok, fine - drop them. If we need to remove them
e.g. because component they address goes away or changes function in a
way that makes it irrelevent - fine, drop them. But doing it just
because very small number of people that we can engage in discussion on
the list (and that's not going to ever change - PHP user community is
vastly larger than people even reading this list, let alone actively
participating in it) think it's not needed IMHO is a very wrong
approach. Sometimes we have no choice but to take decisions with this
incomplete knowledge - but here we have a perfectly good option of just
leaving it alone. All other options should be weighted against it.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Andrea Faulds]

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 between two different 
legacy 8-bit encodings used for Hebrew, especially when one of them is just the 
other with nl2br() included! Users who need to convert between different 
variants of ISO-8859-8 can use iconv() instead, or perhaps use a userland 
polyfill of hebrev/c().


I'm not aware that you can use iconv to convert visual to logical Hebrew or 
vice versa.  Not saying you can't, just that I'm not aware it does - I don't 
think it support visual encodings at all.  Do you know how to convert between 
them using iconv?  If you do, I'm fine reimplementing these functions using 
iconv, again, if we can eliminate the pointless upgrade hassle.  The other 
alternative of a userland version isn't that simple to write, would be slower, 
and most importantly buys us nothing.


Looking into it, iconv() doesn't seem to support converting between 
ISO-8859-8 and ISO-8859-8-I, at least on my system. Nor can 
mb_convert_encoding(). Both only support ISO-8859-8.


I should have researched this before. hebrev() isn't redundant, then, 
sorry about that.



I'm guessing that hebrevc() predates nl2br() (could be wrong), but regardless, 
I wouldn't touch it as there's zero gain to be had.


Ah, that might explain the difference.


Last - we're not or at least shouldn't be doing mass deprecations.  There 
should be an extremely strong reason to break perfectly good code.


Yeah, I'd be cautious about removing any of these. I do think these 
functions should be moved in the manual (and possibly source), though.


Thanks for your input.
--
Andrea Faulds
https://ajf.me/

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Stanislav Malyshev]

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 deeply
misguided. Yes, there are functions that are very niche and maybe not a
lot of people use them. But the advantage of PHP was always to try and
serve a lot of needs and be a versatile pragmatic instrument, even at
the expense of theoretical purity. I do not think we should abandon this
approach. If there is a conceivable use case where this function can be
useful, and it does not impede progress or prevent implementation of
better features - IMO there's no reason at all to remove it. It's better
to have a hundred of functions and have 10 year old code running
perfectly in modern version than to have new squeaky clean API than has
no code to run because 100% of existing code can not use this version
(and thus even if people wanted to use clean API in new code they can't
because old one does not work).
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Zeev Suraski]

> 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 
> legacy 8-bit encodings used for Hebrew, especially when one of them is just 
> the other with nl2br() included! Users who need to convert between different 
> variants of ISO-8859-8 can use iconv() instead, or perhaps use a userland 
> polyfill of hebrev/c().

I'm not aware that you can use iconv to convert visual to logical Hebrew or 
vice versa.  Not saying you can't, just that I'm not aware it does - I don't 
think it support visual encodings at all.  Do you know how to convert between 
them using iconv?  If you do, I'm fine reimplementing these functions using 
iconv, again, if we can eliminate the pointless upgrade hassle.  The other 
alternative of a userland version isn't that simple to write, would be slower, 
and most importantly buys us nothing.


I'm guessing that hebrevc() predates nl2br() (could be wrong), but regardless, 
I wouldn't touch it as there's zero gain to be had.

Last - we're not or at least shouldn't be doing mass deprecations.  There 
should be an extremely strong reason to break perfectly good code.

Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

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

[Fleshgrinder]

-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 for each PHP operator), but it's trivially polyfillable,
> and it'd be better if people were implementing it themselves (and
> thus knowing it's based on eval()) than using it directly without
> this knowledge.
> 
> Regarding rand() and srand(), I'm fine with getting rid of them.
> Note that we should also deprecate getrandmax() at the same time,
> though. It's the function which returns the C RAND_MAX constant.
> 
> 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 legacy 8-bit encodings used for
> Hebrew, especially when one of them is just the other with nl2br()
> included! Users who need to convert between different variants of
> ISO-8859-8 can use iconv() instead, or perhaps use a userland
> polyfill of hebrev/c().
> 
> That said, hebrev/c() might be used a lot in legacy code, and
> there's probably little harm in keeping it. Similarly, we have
> utf8_decode() and utf8_encode() for converting between ISO-8859-1
> and UTF-8, which could also be replaced with iconv(), but they're
> probably heavily used.
> 
> Even if we don't get rid of or deprecate any of those functions,
> they should probably be moved into a more appropriate section of
> ext/ and the manual.
> 
> Thanks!
> 

+1 for all that are in the RFC and I would like to second Andrea’s
proposals. All of them including utf8_encode() and utf8_decode().
Those two are used incorrectly in most cases I encounter them. People
seem to assume that they are able to encode anything to proper UTF-8
when calling utf8_encode().

There are more questionable string functions available:

- - quotemeta() -- bad function name and purpose is unclear.
- - convert_cyr_string() -- iconv() again ...

Candidates for moving to appropriate section of ext/ (or PECL) since
they are all kind of special and nothing a *normal* program would ever
need. Especially since they target English only and there are much
better algorithms and tools available to work with such use cases.

- - levenshtein()
- - metaphone()
- - similar_text()
- - soundex()

- -- 
Richard "Fleshgrinder" Fussenegger
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWxioTAAoJEOKkKcqFPVVrE8oQAL4GmeeBFGTBiE90sYutyljz
hkAZEKBkFVnSK1Ta92DB4+3mWYYtce7C6th9QsqXP871+XAQ92E69YTjP0GrcAm+
Q62kHWzhtDwsN1cePz3DVfuiuNZ0d2mGWoW4ak1azMhWbQGjx+c7nEiugmWOzsRO
WjSJrd2SoZClSy/yGhmqs/5OFdj3hlnI4KX0xsM4A03I+reKqZc3VOWyZFXOqjBK
VK+Bj8G8hz5bNYk3WFXr2NNA8/r4FAOdOZS4CSsfHTbux/8szqbz2dB2V7oUU9FV
8Z5tpPNPe37GyLjcxvlqcM8QGVjwc3zbxoFK2Jfz6UlnRQxDqH/6XRqNMQF1JslS
7FS8jc57SaUb/9tcg+XwOOkH6yoc30JXjq1BBR0SuNGCB1HDG4vcvWIus2YcI0xO
hhPmp/8Rqujv0ybhuikPBdM1XK5E/3dk+G9xsE2sXNWRYbaeu1moahm52RUWnoFx
YNAHeYIsA3M1LSncFwiTop6ouqmAAN55wo1rGfocilrwo4lPBF0F6TP8LEeT55vb
AwS70sp/gVfyoTN3MEzubn5XZ3jKft82ZEWIdEBwGs7L3BctE2ubCDozrOBqes9W
sVcj2zhQV636BC8UbKx0x+5PzlGFDX7xayWvP1J8aks+Th35G7WkU4gb5ajLLXOa
W2sMr3dl5EzfgKVLI6+n
=Ip+5
-END PGP SIGNATURE-

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php