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

[Andrey Andreev]

Hi,

On Sat, Jun 22, 2019 at 3:59 PM Nikita Popov  wrote:
>
> On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev  wrote:
>>
>> Hi,
>>
>> With regards to the array_key_exists() deprecation, the RFC currently
>> says nothing about things like ArrayAccess and object properties that
>> contain arrays. I'm sure that these are exceptions that aren't meant
>> to be deprecated, but can you please specify that explicitly? We all
>> know how little bits like that can result in awful outcomes.
>
>
> Thanks for bringing this up: It's a great example of why this needs to be 
> deprecated. array_key_exists() actually has no support for ArrayAccess 
> objects at all -- it only operates on (mangled) object properties. But just 
> seeing the name and the fact that it doesn't error when passed an ArrayAccess 
> object, it's quite easy to jump to the wrong conclusion. I've updated the RFC 
> to mention this now.
>

Well, then I guess actually implementing ArrayAccess support should be
brought up now, but other than that the updated RFC content makes much
more sense now. Thank you.

> I don't understand what you mean by "object properties that contain arrays" 
> though, or rather how that related to array_key_exists().
>

I had a minor brain fart while originally thinking about this and it's
actually nothing. Sorry about that.

Cheers,
Andrey.

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

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

[Christoph M. Becker]

On 22.06.2019 at 21:31, Stanislav Malyshev wrote:

>> While I understand where you are coming from on this, I do think that
>> functionality that is better supported by dedicated extensions to do
>> the job instead of providing some functions in the standard library
>> that converts from a few specific encodings to another:
>
> It may be supported by other extensions (btw did anybody verify that it
> actually is and gives the same results?), but this is not the reason per
> se to remove old working functions. There's a lot of duplication in
> programming languages - all (Turing-complete) languages ultimately do
> the same thing, and most practical languages have way more syntax and
> utility functions than strictly necessary to achieve desired outcome.
> This is because redundancy in expressiveness improves productivity.
> Here we have the reverse - we are forcing people who have working code
> to go back and rewrite it to essentially achieve the same result we
> already have - negative productivity. I don't see a point in doing this.

An alternative of rewriting such code would be to have the function
defined somewhere else; this could be in userland code (and maybe
somebody will make a composer package available), and this could also be
in a custom extension (and perhaps somebody publishes a respective
extension on PECL).

Thanks,
Christoph

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

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

[Nikita Popov]

On Sat, Jun 22, 2019 at 10:27 PM Bruce Weirdan  wrote:

> On Sat, Jun 22, 2019 at 6:32 PM Nikita Popov  wrote:
> >
> > The normal str_starts_with() function is perfectly  safe to use on UTF-8
> strings,
>
> Only if you assume strings to be normalized to the same form. Checking if
> NFC
> string starts with NFD substring by checking them bit by bit is going
> to yield false negatives [1]
>
> [1] https://3v4l.org/4HgUL
>

That's correct, but not really relevant in the context of the discussion,
as mbstring does not perform Unicode normalization, so mb_* functions
wouldn't change anything about this. (Not that basic string operations
should be performing implicit Unicode normalization...)

Nikita

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

[Bruce Weirdan]

On Sat, Jun 22, 2019 at 6:32 PM Nikita Popov  wrote:
>
> The normal str_starts_with() function is perfectly  safe to use on UTF-8 
> strings,

Only if you assume strings to be normalized to the same form. Checking if NFC
string starts with NFD substring by checking them bit by bit is going
to yield false
negatives [1]

[1] https://3v4l.org/4HgUL


-- 
  Best regards,
  Bruce Weirdan mailto:weir...@gmail.com

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

Re: [PHP-DEV] [RFC] Deprecations for 7.4 - specifics

[Stanislav Malyshev]

Hi!

enable_dl - I am not clear what is proposed - to remove dl()
functionality in PHP 8 completely, even in CLI? Or to keep it in CLI
always on and remove the directive?
My opinion: drop the directive, let the SAPI decide if dl() is possible,
with CLI keeping it. Not sure about embed though. But I guess if
somebody needs it in embed, they probably could patch it so it enables
the dl(). Not sure how easy it would be to make this per-SAPI decision
though...

The 'real' type - see no reason to touch it, it doesn't hurt anybody.

hebrev, hebrevc, apache_request_headers, is_writeable,
convert_cyr_string, money_format, restore_include_path - leave them in
peace (argued why in another thread). Maybe legacy extension as Zeev
suggested, I'm fine with that.

Magic quotes and all related - burn with fire. Magic quotes was a
mistake, and here my BC inner voice is not able to say anything in its
favor.

array_key_exists(object) - fine with dropping object behavior. It does
say "array".
And btw, can we actually make it work with ArrayAccess properly?

INPUT_SESSION & INPUT_REQUEST - if they weren't implemented, drop them.
No point in keeping stuff that doesn't work.

register_argc_argv - support making $argc/$argv always available in CLI
but not sure about the definition of CLI. Does CGI qualify? Does embed?
This worries me a bit. Same situation as in dl() - it's like we need
some ini setting that is only accessible to SAPIs... Maybe we should
introduce new INI level that is only settable by SAPI but not changeable
later? Just brainstorming here.

Reflection export() - check if any real code is using it. Reflection
printing is kinda-sorta is the area that BC breaks may be acceptable,
since it's unlikely production code paths would depend on it, but we
need to check it. Undecided so far.

mb_strrpos - if we promised to deprecate, we may as well do it.

implode() - leave it alone, yes I know it's weird order, but messing
with it helps nobody. Yes, I know, "inconsistent". Making it
"consistent" will improve the life of exactly 0 people. Please let it be.

ezmlm_hash - undecided... it's really the niche of the niche. It also
doesn't hurt anyone, but not sure if anybody actually using it anymore.

allow_url_include - as I said, needs separate RFC. I am leaning towards
removing it, but maybe there's some use case for it...

Unbinding $this - already wrote about it, doesn't look like we have a
choice there given that what it is trying to do seems not to be
supported in PHP 8. So there may not be a point in even voting on it,
unless I misunderstand the explanation. If we need a vote, may be a good
idea to separate this one either.
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

[Ben Ramsey]

> On Jun 22, 2019, at 10:32, Nikita Popov  wrote:
> 
>> On Thu, Jun 20, 2019 at 12:32 AM  wrote:
>> 
>> I sent this earlier this week without [RFC] in the subject line...since
>> some people might have filters to check the subject line I wanted to
>> send this again with the proper substring in the subject line–to make it
>> clear I intend to take this to a vote in two weeks. Apologies for the
>> duplicate email.
>> 
>> -Will
>> 
>>> On 2019-06-18 14:45, w...@wkhudgins.info wrote:
>>> Hello all,
>>> 
>>> I submitted this RFC several years ago. I collected a lot of feedback
>>> and I have updated the RFC and corresponding github patch. Please see
>>> the RFC at https://wiki.php.net/rfc/add_str_begin_and_end_functions
>>> and the github patch at https://github.com/php/php-src/pull/2049. I
>>> have addressed many concerns
>>> (order of arguments, name of functions, multibye support, etc). I plan
>>> to move this RFC to a vote in the coming weeks.
>>> 
>>> Thanks,
>>> 
>>> Will
>> 
> 
> Unfortunately, this looks like a case where the RFC feedback has made the
> proposal worse, rather than better :(
> 
> I think it's easier to start with what I think this proposal should be:
> There should be just two functions, str_starts_with() and str_ends_with()
> -- and that's it.
> 
> The important realization to have here is that these functions are a bit of
> sugar for an operation that is quite common, but can also be easily
> implemented with existing functions (using strcmp, strpos or substr,
> depending on what you like). There is no need for us to cover every
> conceivable combination, just make the common case more convenient and
> easier to read.
> 
> With that in mind:
> * I believe the "starts with" and "ends with" naming is a lot more
> canonical, used by Python, Ruby, Java, JavaScript and probably lots more.
> * In my experience case-insensitive "i" variants of strings functions are
> used much less, by an order of magnitude. With this being sugar in the
> first place, I don't think there's a need to cover case-insensitive
> variations (and from a quick look, these don't seem to be first class
> methods in other languages either). If we do want to have them, I'd suggest
> making the names str_starts_with_ci() and str_ends_with_ci(), which is more
> obvious and harder to miss than str_istarts_with() etc.
> * Having mb_* variants of these functions doesn't really make sense. I
> realize that there's this knee-jerk reaction about how if it doesn't have
> "mb" in the name it's not Unicode compatible, but in this case it's even
> more wrong than usual. The normal str_starts_with() function is perfectly
> safe to use on UTF-8 strings, the only difference between it and
> mb_str_starts_with() is that it's going to be implemented a lot more
> efficiently. The only case that *might* make some sense is the
> case-insensitive variant here, because that has some genuine reliance on
> the character encoding. But then again, this can be handled by case-folding
> the strings first, something that mbstring is going to do internally anyway.
> 
> I would happily accept a proposal for str_starts_with() + str_ends_with(),
> but I'm a lot more apprehensive about adding these 8 new functions.
> 
> Regards,
> Nikita


I like the idea of simplifying this to the two functions str_starts_with() and 
str_ends_with().

When I was looking through this the other day, I had trouble coming up with an 
example of a string with the mb_* versions would ever generate a different 
result from the non-multibyte versions, since the implementation only needs to 
count and analyze bytes for uniqueness. Perhaps it would only be an issue with 
the case-insensitive versions, as Nikita points out? If so, can someone provide 
some example strings where an mb_starts_with_ci() would return true, while 
str_starts_with_ci() would return false?

I think the case sensitivity versions would be common enough in use cases (i.e. 
looking to see if a path ends with .CSV vs. .csv, etc.), but maybe the 
signatures could be revised to pass a third parameter?

str_starts_with($haystack, $needle, $case_sensitive = true): bool

-Ben

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

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

[Stanislav Malyshev]

Hi!

> In general, something is considered a primary vote if it could be
> conducted independently of other primary votes in the same RFC - ie, it
> is not an implementation detail.
> 
> So, what we have here is multiple primary votes ...

I am not talking bureaucracy here, I'm talking about discussion on the
merits. It is virtually impossible to discuss 20 proposals on the merits
within a single thread. Of course, in this RFC there are not 20
different proposals - most of it is of the same type, deprecating
certain function, usually for the same reason (which I coincidentally
believer is wrong, but that's for another thread).

However, some of these are of a different types, and I think they'd be
better as separate RFCs. Especially the allow_url_include thing and
closure $this thing (which I'm not sure even needs an RFC if I
understand the argument right - we pretty much have no choice there).
Discussing them all together would be messy.

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

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

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

[Stanislav Malyshev]

Hi!

> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:

It may be supported by other extensions (btw did anybody verify that it
actually is and gives the same results?), but this is not the reason per
se to remove old working functions. There's a lot of duplication in
programming languages - all (Turing-complete) languages ultimately do
the same thing, and most practical languages have way more syntax and
utility functions than strictly necessary to achieve desired outcome.
This is because redundancy in expressiveness improves productivity.
Here we have the reverse - we are forcing people who have working code
to go back and rewrite it to essentially achieve the same result we
already have - negative productivity. I don't see a point in doing this.

> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with

It works.

> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support  lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?

I see multiple references to it in code online. If it works for people
that use it - why touch it? I even see porting it to other languages,
like Javascript. Pretty weird for a function that nobody ever needs,
isn't it?

> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a

I don't see it as a complaint at all. "Library provides many functions"
- this is a *complaint*?! This is pretty much why PHP became popular!
I know there are people online that enjoy writing nitpicky snide
articles about how PHP is "inconsistent". I say - let them. Internet is
big, anybody can write anything, it's not a reason to take to heart
everything random people on the internet write. Satisfying those people
- some of whom aren't even PHP users - is infinitely less important than
the time of actual PHP users that actually use the language. And I do
not see who of the actual PHP users these removals would help.

"Consistency" is only helpful when it improves something and makes work
easier. Nothing is made easier by removing functions that work.

> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.

It is very common in virtually all programming languages to have utility
functions to support special cases, even if there's a library that
supports more generic case. You have your regular expression library,
and then you have functions that parse dates, or numbers, or phone
numbers - even though regex library alone enough to implement those. It
is a very common and standard practice. Moreover, we're not talking
about introducing new functionality here - we're talking about removing
functionality that people *already use in their code*. The bar for this
should be super-high. In fact, excluding clear blunders like magic
quotes, etc. if we never ever removed a working function, I'd be fine
even with that. But if we decide to remove, it should be for reasons far
better than "you can do it with other functions" - that never was the
PHP way and shouldn't be.

> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical

What you call "convoluted" I call "convenient and versatile". Having
many functions to help people do what they need is good. We don't pay
per function. There's no goal to have as few functions as possible.

> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.

I don't see how this is "evolving", if you understand evolving as
getting more fit for the purpose. I do not recognize "having as few
functions as possible" as a goal worth pursuing, so what's the point?

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

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

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

[Nikita Popov]

On Sat, Jun 22, 2019 at 6:11 PM Pieter Hordijk 
wrote:

>
>
> > Also, it's unclear to me why get_called_class() should be deprecated.
> > While the rest of the listed deprecations have either motivation
> > written for them or are self-evidently legacy functionalities that
> > nobody should be using today, this one seems to be just a case of
> > "let's not have more than one way of doing things" and I'm not really
> > a fan of that.
>
> I agree with above. When looking through the list of deprecations this
> one jumps out for me as being an outlier too.
>
> Maybe it should just be removed from the RFC?


As we all seem to agree on this one (Kalle as well), I went ahead and
dropped it from the RFC.

Nikita

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

[Pieter Hordijk]

 
> Also, it's unclear to me why get_called_class() should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have more than one way of doing things" and I'm not really
> a fan of that.

I agree with above. When looking through the list of deprecations this
one jumps out for me as being an outlier too.

Maybe it should just be removed from the RFC?

Pieter

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

Re: [PHP-DEV] [RFC] Desire to move RFC add_str_begin_and_end_functions to a vote

[Nikita Popov]

On Thu, Jun 20, 2019 at 12:32 AM  wrote:

> I sent this earlier this week without [RFC] in the subject line...since
> some people might have filters to check the subject line I wanted to
> send this again with the proper substring in the subject line–to make it
> clear I intend to take this to a vote in two weeks. Apologies for the
> duplicate email.
>
> -Will
>
> On 2019-06-18 14:45, w...@wkhudgins.info wrote:
> > Hello all,
> >
> > I submitted this RFC several years ago. I collected a lot of feedback
> > and I have updated the RFC and corresponding github patch. Please see
> > the RFC at https://wiki.php.net/rfc/add_str_begin_and_end_functions
> > and the github patch at https://github.com/php/php-src/pull/2049. I
> > have addressed many concerns
> > (order of arguments, name of functions, multibye support, etc). I plan
> > to move this RFC to a vote in the coming weeks.
> >
> > Thanks,
> >
> > Will
>

Unfortunately, this looks like a case where the RFC feedback has made the
proposal worse, rather than better :(

I think it's easier to start with what I think this proposal should be:
There should be just two functions, str_starts_with() and str_ends_with()
-- and that's it.

The important realization to have here is that these functions are a bit of
sugar for an operation that is quite common, but can also be easily
implemented with existing functions (using strcmp, strpos or substr,
depending on what you like). There is no need for us to cover every
conceivable combination, just make the common case more convenient and
easier to read.

With that in mind:
 * I believe the "starts with" and "ends with" naming is a lot more
canonical, used by Python, Ruby, Java, JavaScript and probably lots more.
 * In my experience case-insensitive "i" variants of strings functions are
used much less, by an order of magnitude. With this being sugar in the
first place, I don't think there's a need to cover case-insensitive
variations (and from a quick look, these don't seem to be first class
methods in other languages either). If we do want to have them, I'd suggest
making the names str_starts_with_ci() and str_ends_with_ci(), which is more
obvious and harder to miss than str_istarts_with() etc.
 * Having mb_* variants of these functions doesn't really make sense. I
realize that there's this knee-jerk reaction about how if it doesn't have
"mb" in the name it's not Unicode compatible, but in this case it's even
more wrong than usual. The normal str_starts_with() function is perfectly
safe to use on UTF-8 strings, the only difference between it and
mb_str_starts_with() is that it's going to be implemented a lot more
efficiently. The only case that *might* make some sense is the
case-insensitive variant here, because that has some genuine reliance on
the character encoding. But then again, this can be handled by case-folding
the strings first, something that mbstring is going to do internally anyway.

I would happily accept a proposal for str_starts_with() + str_ends_with(),
but I'm a lot more apprehensive about adding these 8 new functions.

Regards,
Nikita

Re: [PHP-DEV] [Discussion] Scalar Object Strings and MultibyteEncodings

[Rowan Collins]

On 20/06/2019 23:30, Mark Randall wrote:
There does at least seem to be the starting point in that mb_string is 
already widely used, and my suggestion that it "work as expected" is 
more that it would work as the equivalent mb_string / iconv function 
would.



I think this is a rather short-sighted way of looking at it. If people 
want the API provided by the mbstring extension, they can just use those 
functions; the advantage of designing a new set of functions is surely 
that we don't need to stick to past decisions. If we start to build a 
new standard library, as Zeev suggested in the deprecation thread, it is 
a once-in-a-lifetime chance to build something better, not just copy 
what's gone before.



mb_strlen returns the number of codepoints for example, I'm not 
immediately seeing anything about mb_string supporting Graphemes as 
the only reference I could find to their manipulation was The intl 
extension.



The mbstring extension was not built for Unicode, but for older Japanese 
multi-byte encodings, where the definition of "character" is much more 
straight-forward. Its Unicode support seems to mostly see code points as 
mappings for characters in some other encoding. (The oldest manual page 
for it on archive.org [1] is from 2001, and includes the quaint remark 
"As Unicode is getting popular, UTF-8 is used also.") The iconv library 
is even more explicitly aimed at converting between character sets, 
rather than understanding them (the extra functions such as iconv_strlen 
are unique to PHP).


Unicode today is much more than a mapping of legacy encodings to a 
universal character set, and I can think of no useful purpose in 
declaring the "string length" of the British flag emoji to be 2, just 
because it is encoded as the sequence U+1F1EC U+1F1E7.



[1] 
http://web.archive.org/web/20010605075550/http://www.php.net/manual/en/ref.mbstring.php


Regards,

--
Rowan Collins
[IMSoP]


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

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

[Nikita Popov]

On Sat, Jun 22, 2019 at 2:24 PM Andrey Andreev  wrote:

> Hi,
>
> With regards to the array_key_exists() deprecation, the RFC currently
> says nothing about things like ArrayAccess and object properties that
> contain arrays. I'm sure that these are exceptions that aren't meant
> to be deprecated, but can you please specify that explicitly? We all
> know how little bits like that can result in awful outcomes.
>

Thanks for bringing this up: It's a great example of why this needs to be
deprecated. array_key_exists() actually has no support for ArrayAccess
objects at all -- it only operates on (mangled) object properties. But just
seeing the name and the fact that it doesn't error when passed an
ArrayAccess object, it's quite easy to jump to the wrong conclusion. I've
updated the RFC to mention this now.

I don't understand what you mean by "object properties that contain arrays"
though, or rather how that related to array_key_exists().

Also, it's unclear to me why get_called_class() should be deprecated.
> While the rest of the listed deprecations have either motivation
> written for them or are self-evidently legacy functionalities that
> nobody should be using today, this one seems to be just a case of
> "let's not have more than one way of doing things" and I'm not really
> a fan of that.
>

Personally I agree. I don't really see a strong motivation for dropping
this function. Kalle?

Nikita

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

[Andrey Andreev]

Hi,

With regards to the array_key_exists() deprecation, the RFC currently
says nothing about things like ArrayAccess and object properties that
contain arrays. I'm sure that these are exceptions that aren't meant
to be deprecated, but can you please specify that explicitly? We all
know how little bits like that can result in awful outcomes.

Also, it's unclear to me why get_called_class() should be deprecated.
While the rest of the listed deprecations have either motivation
written for them or are self-evidently legacy functionalities that
nobody should be using today, this one seems to be just a case of
"let's not have more than one way of doing things" and I'm not really
a fan of that.

Cheers,
Andrey.

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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

[Zeev Suraski]

On Mon, Jun 17, 2019 at 1:55 PM Nikita Popov  wrote:

> On Fri, May 24, 2019 at 6:53 PM Peter Kokot  wrote:
>
> > Hello,
> >
> > On Sat, 11 May 2019 at 20:56, Peter Kokot  wrote:
> > >
> > > Not trying to rush anyone to something they have no energy working on
> > > anymore here but what's the plan here then? And what plan is there
> > > with these short tags on the long run?
> >
> > I'm just checking then why is this RFC in the pending implementation
> > state if basically we're on a way to have the short opening tags in
> > PHP for ever... Maybe we should then enable them by default to have
> > the other way around situation of having both tags for few 10 years
> > and then ditch the long one if it's not going to be deprecated in PHP
> > 7.4 and decided what to do with them?
> >
> > https://wiki.php.net/rfc/deprecate_php_short_tags
> >
>
> Girgias has put up a new implementation at
> https://github.com/php/php-src/pull/4263.
>
> If short_open_tag=On and  thrown. short_open_tag=On remains the default, so there will be no
> accidental code leakage due to changed defaults. If short_open_tag=Off,
> then 
> I believe that addresses the implementation concerns and we can go ahead
> with landing this RFC.
>

Nikita,

I wrote a fairly detailed response to why I believe we should re-do the RFC
and vote, given multiple issues with the original one.  While there was a
response to it, I very much stand by what I said in it - namely, that the
discussion was toe-deep in a way that is unbecoming for such a basic
building block (as unpopular as it may be), that some of the motivations
mentioned in the RFC were simply wrong (e.g. 'simplification of the
parser') and that the voting options were confusing - which may have
impacted the vote in certain ways.  I see no way forward other than redoing
it.  This feature has been with us for over 20 years, we can spend a couple
of more weeks deprecating it properly if we really need to (and perhaps
consider the 'legacy' extension option - providing a win-win of sorts,
where we can both move forward with 'cleanups' - but also provide a
painless path forward for the ones affected).

Zeev

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

[Zeev Suraski]

On Sat, Jun 22, 2019 at 10:23 AM Kalle Sommer Nielsen  wrote:

> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalys...@gmail.com>:
> > My first question for many of those is - why? I.e. it deprecates a bunch
> > of niche functions. Most people do not use these functions, so they
> > probably don't care. Those they do use them would find their code broken
> > or produce new warnings and needs to be changed. I have hard time
> > identifying whose life would be made better by these changes.
> >
> > Now, if some of these functions are hopelessly broken or have no valid
> > use cases - like magic quotes - then phasing them out makes sense, and
> > the audience whose life can be made better are people who use those
> > unaware of them being broken, or plan to use them and would thus have
> > broken code unless we warn them (or remove the functions, eventually).
> >
> > But for functions that work just fine, I see absolutely no reason to
> > introduce friction without any apparent upside.
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>

Kalle,

I see very few ways in which you'd be able to convince anybody whose code
was impacted by these removals that they're better off having to audit
their code and learn new library semantics - instead of, well, doing
nothing.

I view this in the same trend as the deprecation of short_tags -
deprecations that may make us feel good, make for a 'more proper' code
base, and bring hassle to our userbase while aiding absolutely no-one in
the process.


> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>

Simple - it harms nobody to keep it, and removing it aids nobody.


> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support  lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>

I've seen hebrev() used as recently as a couple of years ago and given that
I'm not very active in the local community - it's probably still being used
in all sorts of use cases when interacting with old legacy systems (e.g.
IBM i).  How are you assuming it's not in use?

One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere.


While I've heard the former complaint very frequently (and I agree with it
entirely), I've quite literally *never* heard the latter complaint.  Not
once.  Niche functionality doesn't bug anybody.  Inconsistent core
functionality bugs mostly everyone.  Bundling the two as if they're the
same, or even similar - is wrong.  Niche functionality isn't in the way of
anybody - and while it's mostly of no use for most people, the few people
who do need it would often be remarkably thankful for finding it available
(hebrev() certainly falls in that category).  These functions have zero
negative footprint - they consume virtually no memory, they don't slow
anything down, and I'd feel very confident arguring they do not pollute the
namespace in any meaningful way (if anybody here ever bumped into someone
that was upset about hebrev() being taken, please raise your hand).

Instead of removing functionality that most find useless but some found
invaluable - why don't we introduce a new extension, 'legacy', that will
include these functions?  It can even be disabled by default.  That way we
don't needlessly and pointlessly make the upgrade path more difficult - or
at least, we make it just marginally so (you'd be able to eliminate a class
of needless compatibility breakages that would otherwise send you auditing
and researching new ways to do exactly the same thing - by simply turning
on an extension).

I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a 

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

[Claude Pache]

> Le 22 juin 2019 à 09:22, Kalle Sommer Nielsen  a écrit :
> 
> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev 
> :
>> My first question for many of those is - why? I.e. it deprecates a bunch
>> of niche functions. Most people do not use these functions, so they
>> probably don't care. Those they do use them would find their code broken
>> or produce new warnings and needs to be changed. I have hard time
>> identifying whose life would be made better by these changes.
>> 
>> Now, if some of these functions are hopelessly broken or have no valid
>> use cases - like magic quotes - then phasing them out makes sense, and
>> the audience whose life can be made better are people who use those
>> unaware of them being broken, or plan to use them and would thus have
>> broken code unless we warn them (or remove the functions, eventually).
>> 
>> But for functions that work just fine, I see absolutely no reason to
>> introduce friction without any apparent upside.
> 
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
> 
> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
> 
> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support  lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
> 
> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
> 
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
> 

PHP has indeed a sheer number of old-school functions and of niche functions, 
but as developer, they don’t bother me as long as I don’t see them.

One occasion where I am bothered, because I see them, is when I explore the 
manual in order to find a function that does some job. Let’s take for example 
the Session Functions:

https://www.php.net/manual/en/ref.session.php 


In the Table of Contents, functions that are actually useful (e.g., 
`session_start()`) are intermixed with legacy functions that relate to some 
obsolete way to handle session variables (e.g. `session_register()`).

For the particular case of Session functions, there is *some* progress since 
few years ago (the days of PHP 5.2), because obsolete functions are clearly 
marked as such on their individual documentation page 
(https://www.php.net/manual/en/function.session-register.php 
; although the 
pink Warning box ought to be at the very top of the page, so I’m not in danger 
to actually read the documentation before realising that it is obsolete). But 
the Table of Contents still needs to be reorganised...


Now, let’s take the manual of String Functions:

https://www.php.net/manual/en/ref.strings.php 


Those may be separated in two groups: the first one for those that are 
recommended/useful for modern code, and the second one for legacy functions 
such as `convert_cyr_string()` and `hebrevc()` that provide functionality that 
are hardly useful today or that are better handled by some other mean.

Moreover, for each of those functions, a pink Warning box might be placed at 
the very top of their documentation page, stating that such function is 
probably not useful or recommended for new or refactored code, and pointing to 
better alternatives when appropriate.

*However*, such documentation improvement, does *not* imply throwing a 
deprecation warning each time the functionality is used. There is no issue for 
legacy code base to continue to use it as long as it is not broken, and as long 
as I don’t see 

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

[Joe Watkins]

Just a note on process.

It is not necessary to hold multiple RFC's:

> For procedural reasons, multiple RFCs may be combined into one, in which
case there may be multiple primary votes.
> Combining multiple RFCs into one does not allow turning a primary vote
into a secondary vote.

In general, something is considered a primary vote if it could be conducted
independently of other primary votes in the same RFC - ie, it is not an
implementation detail.

So, what we have here is multiple primary votes ...

[1] https://wiki.php.net/rfc/voting

Cheers
Joe



On Sat, 22 Jun 2019 at 09:23, Kalle Sommer Nielsen  wrote:

> Hi
> Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev <
> smalys...@gmail.com>:
> > My first question for many of those is - why? I.e. it deprecates a bunch
> > of niche functions. Most people do not use these functions, so they
> > probably don't care. Those they do use them would find their code broken
> > or produce new warnings and needs to be changed. I have hard time
> > identifying whose life would be made better by these changes.
> >
> > Now, if some of these functions are hopelessly broken or have no valid
> > use cases - like magic quotes - then phasing them out makes sense, and
> > the audience whose life can be made better are people who use those
> > unaware of them being broken, or plan to use them and would thus have
> > broken code unless we warn them (or remove the functions, eventually).
> >
> > But for functions that work just fine, I see absolutely no reason to
> > introduce friction without any apparent upside.
>
> While I understand where you are coming from on this, I do think that
> functionality that is better supported by dedicated extensions to do
> the job instead of providing some functions in the standard library
> that converts from a few specific encodings to another:
>
> convert_cyr_string() -- This uses a non standard set of encoding names
> and only for cyrillic like encodings, what justifications is there for
> keeping this in the standard library over using ext/intl with
> UConverter that supports a much larger set of encodings in a much more
> generic way for more than just cyrillic encodings?
>
> hebrev(), hebrevc() -- These functions were designed for the web era
> pre IE6 where some browsers did not support  lang="he">, what use case is there for these now that the web has
> evolved so much in the past two decades since these were added to do
> this on a backend?
>
> One of the biggest complaints we have in regards to the standard
> library is that it is inconsistent, it provides very niche
> functionality that is better supported elsewhere. I think it is a
> perfect opportunity to review these legacy blocks and direct users to
> better alternatives instead of us having to support many ways of doing
> the same thing. Why should the standard library support only a subset
> of conversion functionality that is so niche and already supported
> much more fluently and abstract in extensions dedicated for the
> matter. I personally think that is a very valid reason to consider
> these functions for deprecations.
>
> We have a large set of aliases that easily can make the standard
> library feel convoluted and therefore also creates a certain technical
> depth as a side-effect. The cost of having to convert these functions
> is a small price to allow the language to evolve in my honest opinion.
>
> > For the specifics, I think things like removing allow_url_include
> > requires separate RFC. It's a serious functionality change, and bundling
> > it with 20 or so other changes would not allow to properly consider it.
> > In general mass-change RFCs usually are not very conductive to properly
> > discussing each specific change, but mixing changes of different types
> > makes it even worse.
>
> I will have a chat with Nikita regarding this.
>
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

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

[Kalle Sommer Nielsen]

Hi
Den lør. 22. jun. 2019 kl. 02.04 skrev Stanislav Malyshev :
> My first question for many of those is - why? I.e. it deprecates a bunch
> of niche functions. Most people do not use these functions, so they
> probably don't care. Those they do use them would find their code broken
> or produce new warnings and needs to be changed. I have hard time
> identifying whose life would be made better by these changes.
>
> Now, if some of these functions are hopelessly broken or have no valid
> use cases - like magic quotes - then phasing them out makes sense, and
> the audience whose life can be made better are people who use those
> unaware of them being broken, or plan to use them and would thus have
> broken code unless we warn them (or remove the functions, eventually).
>
> But for functions that work just fine, I see absolutely no reason to
> introduce friction without any apparent upside.

While I understand where you are coming from on this, I do think that
functionality that is better supported by dedicated extensions to do
the job instead of providing some functions in the standard library
that converts from a few specific encodings to another:

convert_cyr_string() -- This uses a non standard set of encoding names
and only for cyrillic like encodings, what justifications is there for
keeping this in the standard library over using ext/intl with
UConverter that supports a much larger set of encodings in a much more
generic way for more than just cyrillic encodings?

hebrev(), hebrevc() -- These functions were designed for the web era
pre IE6 where some browsers did not support , what use case is there for these now that the web has
evolved so much in the past two decades since these were added to do
this on a backend?

One of the biggest complaints we have in regards to the standard
library is that it is inconsistent, it provides very niche
functionality that is better supported elsewhere. I think it is a
perfect opportunity to review these legacy blocks and direct users to
better alternatives instead of us having to support many ways of doing
the same thing. Why should the standard library support only a subset
of conversion functionality that is so niche and already supported
much more fluently and abstract in extensions dedicated for the
matter. I personally think that is a very valid reason to consider
these functions for deprecations.

We have a large set of aliases that easily can make the standard
library feel convoluted and therefore also creates a certain technical
depth as a side-effect. The cost of having to convert these functions
is a small price to allow the language to evolve in my honest opinion.

> For the specifics, I think things like removing allow_url_include
> requires separate RFC. It's a serious functionality change, and bundling
> it with 20 or so other changes would not allow to properly consider it.
> In general mass-change RFCs usually are not very conductive to properly
> discussing each specific change, but mixing changes of different types
> makes it even worse.

I will have a chat with Nikita regarding this.



-- 
regards,

Kalle Sommer Nielsen
ka...@php.net

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