Re: [PHP-DEV] Deprecation ideas for PHP 8

[Midori Koçak]

Totally agree with this. The new and old can exist both. We should be open
to change.

On Thu, 31 Jan 2019, 11:53 Benjamin Morel  Please forgive my stubborness, too. I fail to see how WordPress supporting
> PHP versions that have been EOL for YEARS can be of any help to the
> community? These versions may have unpatched security holes, and
> encouraging users to keep using them is a disfavour to the community IMO,
> which can only delay adoption of newer versions, and lead to an even more
> painful upgrade path when you have to upgrade N versions at once. My stance
> on this is that projects written in PHP have to evolve together with the
> language, and I'm personally not surprised to have to rewrite a few things
> whenever a major PHP version is released (and I do maintain quite a number
> of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
> my projects towards a more consistent PHP language.
>
> That being said, I know this opinion is a minority on this list, so let's
> put it aside for a moment.
>
> Now what prevents PHP from adding consistent function names / APIs, and
> deprecating the older ones? We can keep the old ones for 10 more years if
> you wish, but at least new PHP code can start using the "correct" ones, and
> progressively the share of PHP code out there using the old ones should
> progressively get lower over the years, up to the point where we could
> eventually decide that it's not worth keeping them. The thing is, if you
> never start, the situation will never improve.
>
> You know the proverb: The best time to plant a tree was 20 years ago. The
> second best time is now.
>
> Ben
>
> On Thu, 31 Jan 2019 at 11:30, Rowan Collins 
> wrote:
>
> > On Thu, 31 Jan 2019 at 07:34, Peter Kokot  wrote:
> >
> > > Sorry, I didn't put my words correctly here. Not inconsistency.
> > > Inconsistency is a fact, yes. I've meant the incapability of doing
> > > something to fix this inconsistency. And it is becoming some sort of
> > > stubborn belief and less and less people want to fix it.
> > >
> > > The RFC: Consistent function names [1] shows the magnitude of this. I
> > > don't think every function listed there needs a change so it can be
> > > greatly reduced. But still this can be done in several years to 10
> > > years or so (measuring over the thumb).
> > >
> >
> >
> > Hi,
> >
> > I'm sorry if I sound stubborn, but I have yet to see a reasonable answer
> to
> > the fundamental problem: the effort needed is not on the part of a few
> > volunteers changing the language, it is effort by *every single user of
> the
> > language*, rewriting *every single PHP program ever written*.
> >
> > WordPress officially supports both PHP 5.2, released 13 years ago, and
> PHP
> > 7.3, released a couple of months ago; one of their biggest challenges in
> > raising that bar is that they, too, have to persuade a community (the
> theme
> > and plugin authors) to change their code to match. That should give you
> > some idea of how long old and new names would have to exist side by side,
> > while we waited for everyone to rewrite all their code, and meanwhile,
> the
> > language would be *even more inconsistent*, because there would be extra
> > ways of writing the same thing.
> >
> > Regards,
> > --
> > Rowan Collins
> > [IMSoP]
> >
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Fri, 1 Feb 2019 at 09:47, Yasuo Ohgaki  wrote:

> Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE)
> names.
> So there wouldn't be compatibility issues for CODING_STANDARD names.
>

I think this would be the worst of both worlds. We would have to
permanently document two different names for every function, examples
(outside of php.net) would still have the old names in, people would
disagree about which to use, and the situation would be more confusing to
new users, not less. This already happens with count() vs sizeof() - people
get used to one or the other, and are confused when they see the other in
someone else's code.


> Bottom line is almost all developers dislike inconsistent names, prefer
> to enter extra few chars.

I think almost all developers would like to spend their effort making
material improvements to the robustness or functionality of their code.
That might include replacing htmlspecialchars with a smarter escaping or
"taint" tracking system; but it woudln't include renaming it in all their
code bases, or debating which of two valid names to use in a new codebase.

Let's focus our effort on writing improved features, and giving them good
names, and if that means some of the older functions become less necessary,
that's a bonus.

>
Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Kalle Sommer Nielsen]

Den fre. 1. feb. 2019 kl. 12.34 skrev Benjamin Morel :
> You have a point here. Couldn't we add a "deprecated log" feature, that
> would log each deprecated function only once? At least we could leave an
> app running for some time, and get a curated list of deprecated features
> from the deprecated log.

I would oppose such a feature as it would make deprecations even more
redundant than disabling them. While they are annoying, they are also
a helpful message to inform our users that this functionality will not
be around, blindly ignoring it and further more giving it its own log
file that doesn't grow nearly as much seems like a bad way to solve
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] Deprecation ideas for PHP 8

[Benjamin Morel]

>  Deprecation notices won't change people's *desire* to change their code.
If you raised a deprecation notice for every call to, say
"htmlspecialchars", the only result would be people turning off deprecation
notices, and missing more important deprecations.

You have a point here. Couldn't we add a "deprecated log" feature, that
would log each deprecated function only once? At least we could leave an
app running for some time, and get a curated list of deprecated features
from the deprecated log.



On Fri, 1 Feb 2019 at 11:11, Rowan Collins  wrote:

> On Thu, 31 Jan 2019 at 22:39, Benjamin Morel 
> wrote:
> >> What if people's muscle memory, their coding standards, their need for
> progressive compatibility, their tools, the tutorials they follow, the code
> snippets they copy, all make it easier to just keep using the old names?
> >> Then our "deprecation" means nothing, and we are stuck with a long list
> of aliases to maintain, and people learning the language scratching their
> heads at inconsistent examples.
>
> > Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
> example, strikes through deprecated method names), and static code analysis
> tools.
>
> Deprecation notices won't change people's *desire* to change their code.
> If you raised a deprecation notice for every call to, say
> "htmlspecialchars", the only result would be people turning off deprecation
> notices, and missing more important deprecations.
>
>
> >>  ... although it takes us close to "completely new language"
> territory.
>
> > Maybe not, if this can be done in a mostly BC way.
>
> It wasn't the BC I was worrying about there, but the possibility that
> projects would adopt one style or the other, and readers coming from an
> "old-style" project might find the code in a "new-style" project rather
> alien. In a worst case scenario, it would feel like we had two languages
> interoperating on the same runtime, like when HHVM hosted both PHP and
> Hack. It's not inevitable, though, just a risk to think about if we ever
> get to that position.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Thu, 31 Jan 2019 at 22:39, Benjamin Morel 
wrote:
>> What if people's muscle memory, their coding standards, their need for
progressive compatibility, their tools, the tutorials they follow, the code
snippets they copy, all make it easier to just keep using the old names?
>> Then our "deprecation" means nothing, and we are stuck with a long list
of aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

> Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

Deprecation notices won't change people's *desire* to change their code. If
you raised a deprecation notice for every call to, say "htmlspecialchars",
the only result would be people turning off deprecation notices, and
missing more important deprecations.


>>  ... although it takes us close to "completely new language"
territory.

> Maybe not, if this can be done in a mostly BC way.

It wasn't the BC I was worrying about there, but the possibility that
projects would adopt one style or the other, and readers coming from an
"old-style" project might find the code in a "new-style" project rather
alien. In a worst case scenario, it would feel like we had two languages
interoperating on the same runtime, like when HHVM hosted both PHP and
Hack. It's not inevitable, though, just a risk to think about if we ever
get to that position.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Yasuo Ohgaki]

On Thu, Jan 31, 2019 at 7:30 PM Rowan Collins 
wrote:

> On Thu, 31 Jan 2019 at 07:34, Peter Kokot  wrote:
>
> > Sorry, I didn't put my words correctly here. Not inconsistency.
> > Inconsistency is a fact, yes. I've meant the incapability of doing
> > something to fix this inconsistency. And it is becoming some sort of
> > stubborn belief and less and less people want to fix it.
> >
> > The RFC: Consistent function names [1] shows the magnitude of this. I
> > don't think every function listed there needs a change so it can be
> > greatly reduced. But still this can be done in several years to 10
> > years or so (measuring over the thumb).
> >
>
>
> Hi,
>
> I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
> the fundamental problem: the effort needed is not on the part of a few
> volunteers changing the language, it is effort by *every single user of the
> language*, rewriting *every single PHP program ever written*.
>
> WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
> 7.3, released a couple of months ago; one of their biggest challenges in
> raising that bar is that they, too, have to persuade a community (the theme
> and plugin authors) to change their code to match. That should give you
> some idea of how long old and new names would have to exist side by side,
> while we waited for everyone to rewrite all their code, and meanwhile, the
> language would be *even more inconsistent*, because there would be extra
> ways of writing the same thing.
>

Hi,

Aliases may stay defined 10, 20 years or even forever for POSIX(IEEE) names.
So there wouldn't be compatibility issues for CODING_STANDARD names.

Christoph suggests namespace for renaming function. This works also.
If namespace is used, it is better to have "PHP" namespace to keep user
namespace clean. IMO.
e.g. PHP\BC\add()
This creates yet another inconsistency with existing modules, though.

Bottom line is almost all developers dislike inconsistent names, prefer
to enter extra few chars.

Consistent name isn't big deal, but keeping inconsistent names for good
doesn't sound nice.

Regards,

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Benjamin Morel]

> The problem comes if the share using the old names *doesn't* decline
enough (and how would we even know?).

We can't survey private projects, but we can run automated analysis tools
on a large number of open-source projects available on GitHub, and compile
statistics from them. I'd be happy to work on such a tool, should it be
useful some day.

> What if people's muscle memory, their coding standards, their need for
progressive compatibility, their tools, the tutorials they follow, the code
snippets they copy, all make it easier to just keep using the old names?
Then our "deprecation" means nothing, and we are stuck with a long list of
aliases to maintain, and people learning the language scratching their
heads at inconsistent examples.

Deprecation notices. Tooling also helps a lot here: IDEs (PHPStorm for
example, strikes through deprecated method names), and static code analysis
tools.

> To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they *want* to upgrade their code to use it...

I do agree with you on that point: I'd rather offer brand new APIs, rather
than just fixing naming inconsistencies. There is so much more than fixing
naming inconsistencies. The error handling, in particular, should be given
some love, by throwing exceptions everywhere, instead of returning false /
triggering warnings. And I would love, too, either your "scalar methods"
approach, or array being an object with built-in map/filter/reduce...

... although it takes us close to "completely new language" territory.

Maybe not, if this can be done in a mostly BC way.

On Thu, 31 Jan 2019 at 12:43, Rowan Collins  wrote:

> On Thu, 31 Jan 2019 at 10:53, Benjamin Morel 
> wrote:
>
>> Please forgive my stubborness, too. I fail to see how WordPress
>> supporting PHP versions that have been EOL for YEARS can be of any help to
>> the community?
>>
>
> I agree, it probably doesn't help the community; but it happens, both in
> open source projects, and in the many private code bases which are written
> in PHP. The more breaking changes we make in the language, the *more*
> likely it is that people will stay on old versions, where their code works
> without modification, and have a negative opinion of upgrades.
>
>
>
>> Now what prevents PHP from adding consistent function names / APIs, and
>> deprecating the older ones? We can keep the old ones for 10 more years if
>> you wish, but at least new PHP code can start using the "correct" ones, and
>> progressively the share of PHP code out there using the old ones should
>> progressively get lower over the years, up to the point where we could
>> eventually decide that it's not worth keeping them.
>>
>
> The problem comes if the share using the old names *doesn't* decline
> enough (and how would we even know?). What if people's muscle memory, their
> coding standards, their need for progressive compatibility, their tools,
> the tutorials they follow, the code snippets they copy, all make it easier
> to just keep using the old names? Then our "deprecation" means nothing, and
> we are stuck with a long list of aliases to maintain, and people learning
> the language scratching their heads at inconsistent examples.
>
> To be more positive, I am all for introducing new ways to do existing
> things in the language where they have real benefits to the user. For
> instance, a new file-handling API, with better error handling, and
> object-based streams, would be great; or a replacement for the frankly
> awful curl functions. Perhaps even a well-designed implementation of
> "scalar methods" (e.g. being able to write [1, 2,
> 3]->map($callback)->filter($callback);) would have users enthusiastic
> enough that they *want* to upgrade their code to use it, although it takes
> us close to "completely new language" territory.
>
> If we can persuade every user of PHP that the change is bringing them a
> real benefit to outweigh the cost of re-writing and re-learning, then we
> can make grand changes to the language; I don't think moving underscores
> around will ever do that.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Thu, 31 Jan 2019 at 10:53, Benjamin Morel 
wrote:

> Please forgive my stubborness, too. I fail to see how WordPress supporting
> PHP versions that have been EOL for YEARS can be of any help to the
> community?
>

I agree, it probably doesn't help the community; but it happens, both in
open source projects, and in the many private code bases which are written
in PHP. The more breaking changes we make in the language, the *more*
likely it is that people will stay on old versions, where their code works
without modification, and have a negative opinion of upgrades.



> Now what prevents PHP from adding consistent function names / APIs, and
> deprecating the older ones? We can keep the old ones for 10 more years if
> you wish, but at least new PHP code can start using the "correct" ones, and
> progressively the share of PHP code out there using the old ones should
> progressively get lower over the years, up to the point where we could
> eventually decide that it's not worth keeping them.
>

The problem comes if the share using the old names *doesn't* decline enough
(and how would we even know?). What if people's muscle memory, their coding
standards, their need for progressive compatibility, their tools, the
tutorials they follow, the code snippets they copy, all make it easier to
just keep using the old names? Then our "deprecation" means nothing, and we
are stuck with a long list of aliases to maintain, and people learning the
language scratching their heads at inconsistent examples.

To be more positive, I am all for introducing new ways to do existing
things in the language where they have real benefits to the user. For
instance, a new file-handling API, with better error handling, and
object-based streams, would be great; or a replacement for the frankly
awful curl functions. Perhaps even a well-designed implementation of
"scalar methods" (e.g. being able to write [1, 2,
3]->map($callback)->filter($callback);) would have users enthusiastic
enough that they *want* to upgrade their code to use it, although it takes
us close to "completely new language" territory.

If we can persuade every user of PHP that the change is bringing them a
real benefit to outweigh the cost of re-writing and re-learning, then we
can make grand changes to the language; I don't think moving underscores
around will ever do that.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Christoph M. Becker]

On 31.01.2019 at 08:34, Peter Kokot wrote:

> The RFC: Consistent function names [1] shows the magnitude of this. I
> don't think every function listed there needs a change so it can be
> greatly reduced. But still this can be done in several years to 10
> years or so (measuring over the thumb).
> 
> Not that it is not possible to do this, but too many people promote
> this state as not possible to change. I didn't put too much effort to
> make a list of all the changes to an extend as is nicely done in the
> RFC but maybe enough would be renaming functions and alias them
> properly from major/minor release version to version and furthermore
> deprecate the aliases, so they match the pattern suggested for PHP
> vanilla functions [2]. Not to mention really good ideas from the past
> discussions with namespacing functions and similar approaches...
> 
> But, yes... Without proper will or motivation from key people who
> could change this it will stay in the inconsistent state and we all
> accept it as is. Specially in discussions about a major release where
> BC could be done.
> 
> [1] https://wiki.php.net/rfc/consistent_function_names
> [2] https://github.com/php/php-src/blob/master/CODING_STANDARDS

In my opinion, there is no gain in renaming bcadd() to bc_add(), for
instance.  A namespaced variant BC\add() might be an improvement, but
likely it should rather be BCNumber::plus() (also overloading the +
operator).  See also the closely related discussion regarding renaming
the image functions: .

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Benjamin Morel]

Please forgive my stubborness, too. I fail to see how WordPress supporting
PHP versions that have been EOL for YEARS can be of any help to the
community? These versions may have unpatched security holes, and
encouraging users to keep using them is a disfavour to the community IMO,
which can only delay adoption of newer versions, and lead to an even more
painful upgrade path when you have to upgrade N versions at once. My stance
on this is that projects written in PHP have to evolve together with the
language, and I'm personally not surprised to have to rewrite a few things
whenever a major PHP version is released (and I do maintain quite a number
of projects). Let me rephrase this: actually, I would be HAPPY to rewrite
my projects towards a more consistent PHP language.

That being said, I know this opinion is a minority on this list, so let's
put it aside for a moment.

Now what prevents PHP from adding consistent function names / APIs, and
deprecating the older ones? We can keep the old ones for 10 more years if
you wish, but at least new PHP code can start using the "correct" ones, and
progressively the share of PHP code out there using the old ones should
progressively get lower over the years, up to the point where we could
eventually decide that it's not worth keeping them. The thing is, if you
never start, the situation will never improve.

You know the proverb: The best time to plant a tree was 20 years ago. The
second best time is now.

Ben

On Thu, 31 Jan 2019 at 11:30, Rowan Collins  wrote:

> On Thu, 31 Jan 2019 at 07:34, Peter Kokot  wrote:
>
> > Sorry, I didn't put my words correctly here. Not inconsistency.
> > Inconsistency is a fact, yes. I've meant the incapability of doing
> > something to fix this inconsistency. And it is becoming some sort of
> > stubborn belief and less and less people want to fix it.
> >
> > The RFC: Consistent function names [1] shows the magnitude of this. I
> > don't think every function listed there needs a change so it can be
> > greatly reduced. But still this can be done in several years to 10
> > years or so (measuring over the thumb).
> >
>
>
> Hi,
>
> I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
> the fundamental problem: the effort needed is not on the part of a few
> volunteers changing the language, it is effort by *every single user of the
> language*, rewriting *every single PHP program ever written*.
>
> WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
> 7.3, released a couple of months ago; one of their biggest challenges in
> raising that bar is that they, too, have to persuade a community (the theme
> and plugin authors) to change their code to match. That should give you
> some idea of how long old and new names would have to exist side by side,
> while we waited for everyone to rewrite all their code, and meanwhile, the
> language would be *even more inconsistent*, because there would be extra
> ways of writing the same thing.
>
> Regards,
> --
> Rowan Collins
> [IMSoP]
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Thu, 31 Jan 2019 at 07:34, Peter Kokot  wrote:

> Sorry, I didn't put my words correctly here. Not inconsistency.
> Inconsistency is a fact, yes. I've meant the incapability of doing
> something to fix this inconsistency. And it is becoming some sort of
> stubborn belief and less and less people want to fix it.
>
> The RFC: Consistent function names [1] shows the magnitude of this. I
> don't think every function listed there needs a change so it can be
> greatly reduced. But still this can be done in several years to 10
> years or so (measuring over the thumb).
>


Hi,

I'm sorry if I sound stubborn, but I have yet to see a reasonable answer to
the fundamental problem: the effort needed is not on the part of a few
volunteers changing the language, it is effort by *every single user of the
language*, rewriting *every single PHP program ever written*.

WordPress officially supports both PHP 5.2, released 13 years ago, and PHP
7.3, released a couple of months ago; one of their biggest challenges in
raising that bar is that they, too, have to persuade a community (the theme
and plugin authors) to change their code to match. That should give you
some idea of how long old and new names would have to exist side by side,
while we waited for everyone to rewrite all their code, and meanwhile, the
language would be *even more inconsistent*, because there would be extra
ways of writing the same thing.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Peter Kokot]

On Wed, 30 Jan 2019 at 20:51, Rowan Collins  wrote:
>
> On 30/01/2019 17:28, Peter Kokot wrote:
> > This now also means that PHP is making its inconsistency a fact
>
>
> The inconsistency IS a fact, and has been for more than 20 years. This
> isn't some new policy, banning something that used to be possible, it's
> a summary of something that's been discussed over and over again, and
> always reached the same conclusion.
>
> The unfortunate truth is that the only way to truly fix most of these
> problems would be to create a completely new language, like Perl6; or at
> least a complete rewrite, like Python 3. As those two examples show, the
> result would be effort and community split between two forks, one that
> runs all the millions of PHP applications already written, and one that
> is theoretically nicer, but runs none of that old code. That just isn't
> a price worth paying.

Sorry, I didn't put my words correctly here. Not inconsistency.
Inconsistency is a fact, yes. I've meant the incapability of doing
something to fix this inconsistency. And it is becoming some sort of
stubborn belief and less and less people want to fix it.

The RFC: Consistent function names [1] shows the magnitude of this. I
don't think every function listed there needs a change so it can be
greatly reduced. But still this can be done in several years to 10
years or so (measuring over the thumb).

Not that it is not possible to do this, but too many people promote
this state as not possible to change. I didn't put too much effort to
make a list of all the changes to an extend as is nicely done in the
RFC but maybe enough would be renaming functions and alias them
properly from major/minor release version to version and furthermore
deprecate the aliases, so they match the pattern suggested for PHP
vanilla functions [2]. Not to mention really good ideas from the past
discussions with namespacing functions and similar approaches...

But, yes... Without proper will or motivation from key people who
could change this it will stay in the inconsistent state and we all
accept it as is. Specially in discussions about a major release where
BC could be done.

[1] https://wiki.php.net/rfc/consistent_function_names
[2] https://github.com/php/php-src/blob/master/CODING_STANDARDS

-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On 30/01/2019 17:28, Peter Kokot wrote:

This now also means that PHP is making its inconsistency a fact



The inconsistency IS a fact, and has been for more than 20 years. This 
isn't some new policy, banning something that used to be possible, it's 
a summary of something that's been discussed over and over again, and 
always reached the same conclusion.


The unfortunate truth is that the only way to truly fix most of these 
problems would be to create a completely new language, like Perl6; or at 
least a complete rewrite, like Python 3. As those two examples show, the 
result would be effort and community split between two forks, one that 
runs all the millions of PHP applications already written, and one that 
is theoretically nicer, but runs none of that old code. That just isn't 
a price worth paying.


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Peter Kokot]

Hello,

On Tue, 22 Jan 2019 at 23:40, Rowan Collins  wrote:
>
> On 22/01/2019 21:27, Midori Koçak wrote:
> > Can we also add strange function names without any naming conventions to
> > this list
>
> In short, no. I wish we had an FAQ where we could avoid recapping the
> arguments around this, but it has come up many times, and the conclusion
> has always been that it's never going to happen.
>
> It would be great if we could invent a time machine and design the
> language differently, but it's too late now, there is just too much code
> out there to "fix".

This now also means that PHP is making its inconsistency a fact and it
will never ever be able to reach the consistency level it should be
at... Specially, if more and more people believe this. I'm not sure
this is the good approach in programming and neither is really a fact,
but who am I to judge this state now. It would be good to avoid having
FAQs and appendixes in coding standards for those
function_name_ext_SomethingElseOutofblue() cases so that it might be
still achieved one day.

-- 
Peter Kokot

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Stephen Reay]

> On 29 Jan 2019, at 07:13, Girgias  wrote:
> 
> On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd  wrote:
> 
>> On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:
>> 
>>> I understand the rationale for functional programming, may I ask
>>> in your opinion should PHP have built-in functions for arithmetic
>>> operations so that it can be used in such a way without needing userland
>>> implementations?
>> 
>> No, but only I'd much strongly prefer we have some syntax for defined
>> 'short closures' ala Javascript:
>> 
>> $values = [1, 2, 3];
>> $bar = array_map($x => $x + 1, $values);
>> 
>> // $values === [2, 3, 4];
>> 
>> as those cover much more than the basic arithmetic operations, are
>> nice and readable after you've used them a few times.
>> 
>> cheers
>> Dan
>> Ack
>> 
> 
> I didn't even know you could omit parenthesis in JS closures, the more you
> know.
> But it seems like there is already a Draft for an RFC for short closures in
> PHP but
> that one seems to have come to a halt.
> 
> I've realised I didn't go through array functions so just gonna bring them
> up for the sake of not creating a new thread:
> 
> 
>   - key_exist - alias of array_key_exist
>   A GitHub search brings up 276 078 results where there are some userland
>   usage but also a whole lot of unit tests usage
>   https://github.com/search?l=PHP&p=1&q=key_exists&type=Code
>   - pos - alias for current
>   Can't seem to get any meaningful result by searching on GitHub as it
>   picks up more or less anything which contains pos
>   https://github.com/search?l=PHP&q=pos%28&type=Code
>   - sizeof - alias of count
>   A Github search brings up 1 617 789 results with lots of userland usage
>   but also a bit of unit testing
>   https://github.com/search?l=PHP&p=1&q=sizeof&type=Code
> 
> And then there is *array_multisort* a function which has a signature which
> isn't even possible in userland code.
> (https://secure.php.net/manual/en/function.array-multisort.php).
> Other than the fact that this function's documentation isn't totally
> correct in my opinion I did a Github search to see if people use it.
>> From what I've seen in the search results [1], around 620k, it is only used
> in phpt unit tests and a unit test of a parser.
> 
> Now, I don't think a function which doesn't follow normal function
> signature converntion (or isn't even possible) shouldn't really be part of
> the language.
> Moreso that it seems barely anybody uses it.
> What's people opinion on deprecating array_multisort ?
> 
> [1]
> https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code
> 
> George P. Banyard


My opinion on deprecating array_multisort is: don’t. 

Plenty of provided functionality exists specifically because it’s stuff that’s 
not feasible or not efficient to do in userland.

Given the fairly unique capabilities of array_multisort, what is your suggested 
replacement for the half-million instances on GitHub alone (lets not forget 
that GitHub is not the single repository of all code ever written, and the 
search you’ve referenced is only public repos)?

If array_multisort is viable for deprecation, surely array_fill is as well? At 
least that one is replaceable with a simple userland implementation. What about 
array_rand? Or array_product - that has a paltry 31K results on GitHub. Or 
array_chunk, that’s only 2/3 as many results as for array_multisort.

Heck, why not remove all built in functions and just force everyone to write 
the entire runtime from scratch in userland code?


In case you didn’t realise, this is sarcasm at the extreme, because your given 
reasons to support deprecation are absurd.




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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Claude Pache]

> 
> And then there is *array_multisort* a function which has a signature which
> isn't even possible in userland code.
> (https://secure.php.net/manual/en/function.array-multisort.php 
> ).
> Other than the fact that this function's documentation isn't totally
> correct in my opinion I did a Github search to see if people use it.
> From what I've seen in the search results [1], around 620k, it is only used
> in phpt unit tests and a unit test of a parser.
> 
> [1]
> https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code 
> 
> 

Presumably, if you sort the results by ”Best match”, test units appear first 
because they are the only occasions where you invoke this function ten times in 
a row. Try to sort by ”Recently indexed” and you’ll get some real usages.

> Now, I don't think a function which doesn't follow normal function
> signature converntion (or isn't even possible) shouldn't really be part of
> the language.
> Moreso that it seems barely anybody uses it.
> What's people opinion on deprecating array_multisort ?

One of the most important things to consider when proposing deprecations is the 
migration cost you impose to your users. It is apparently something easily 
forgotten by those that love deprecations : “In order to make migrating your 
legacy code even more painful, we have carefully chosen to deprecate a function 
that you’ll have trouble to reimplement userland.”

Moreover, even when assuming (incorrectly) that it is barely used: What is the 
benefit of deprecating array_multisort? (This question is valid also for future 
deprecation proposals.)

—Claude

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Thu, 24 Jan 2019 at 01:25, Dan Ackroyd  wrote:

> On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:
>
> > I understand the rationale for functional programming, may I ask
> > in your opinion should PHP have built-in functions for arithmetic
> > operations so that it can be used in such a way without needing userland
> > implementations?
>
> No, but only I'd much strongly prefer we have some syntax for defined
> 'short closures' ala Javascript:
>
> $values = [1, 2, 3];
> $bar = array_map($x => $x + 1, $values);
>
> // $values === [2, 3, 4];
>
> as those cover much more than the basic arithmetic operations, are
> nice and readable after you've used them a few times.
>
> cheers
> Dan
> Ack
>

I didn't even know you could omit parenthesis in JS closures, the more you
know.
But it seems like there is already a Draft for an RFC for short closures in
PHP but
that one seems to have come to a halt.

I've realised I didn't go through array functions so just gonna bring them
up for the sake of not creating a new thread:


   - key_exist - alias of array_key_exist
   A GitHub search brings up 276 078 results where there are some userland
   usage but also a whole lot of unit tests usage
   https://github.com/search?l=PHP&p=1&q=key_exists&type=Code
   - pos - alias for current
   Can't seem to get any meaningful result by searching on GitHub as it
   picks up more or less anything which contains pos
   https://github.com/search?l=PHP&q=pos%28&type=Code
   - sizeof - alias of count
   A Github search brings up 1 617 789 results with lots of userland usage
   but also a bit of unit testing
   https://github.com/search?l=PHP&p=1&q=sizeof&type=Code

And then there is *array_multisort* a function which has a signature which
isn't even possible in userland code.
(https://secure.php.net/manual/en/function.array-multisort.php).
Other than the fact that this function's documentation isn't totally
correct in my opinion I did a Github search to see if people use it.
>From what I've seen in the search results [1], around 620k, it is only used
in phpt unit tests and a unit test of a parser.

Now, I don't think a function which doesn't follow normal function
signature converntion (or isn't even possible) shouldn't really be part of
the language.
Moreso that it seems barely anybody uses it.
What's people opinion on deprecating array_multisort ?

[1]
https://github.com/search?l=PHP&o=desc&p=1&q=array_multisort&s=&type=Code

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Dan Ackroyd]

On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:

> I understand the rationale for functional programming, may I ask
> in your opinion should PHP have built-in functions for arithmetic
> operations so that it can be used in such a way without needing userland
> implementations?

No, but only I'd much strongly prefer we have some syntax for defined
'short closures' ala Javascript:

$values = [1, 2, 3];
$bar = array_map($x => $x + 1, $values);

// $values === [2, 3, 4];

as those cover much more than the basic arithmetic operations, are
nice and readable after you've used them a few times.

cheers
Dan
Ack

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Tom Worster]

Hi George,

Iiuc, the problem you're trying to solve is that PHP offers too many 
ways to do the same thing and if there were fewer then PHP code would be 
easier to write, read and maintain.


Differences in code that make no difference to the compiler are 
differences in style.


The conventional solution is to adopt a style spec and use a linter. 
I've experienced this in Ruby, JS and PHP and it's effective.


This conventional solution causes a lot less breakage than attempting to 
mitigate the problem by changing the language.


It's annoying enough to have to deal with the promulgation of a new 
style spec and corresponding linter in your organization. Imagine if 
such a change were to be promulgated by The Rulers of PHP.


Tom

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Christoph M. Becker]

On 23.01.2019 at 18:30, Rowan Collins wrote:

> On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:
> 
>> I understand the rationale for functional programming, may I ask
>> in your opinion should PHP have built-in functions for arithmetic
>> operations so that it can be used in such a way without needing userland
>> implementations?
> 
> There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
> Seems like the kind of thing either of them might work on...) to add a
> syntax for using any operator as a callable. I don't think it got beyond a
> thought experiment, but it's an interesting concept, and would
> theoretically remove the need for some of this duplicate functionality.

See  (which is still “under
discussion”, by the way).

-- 
Christoph M. Becker

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Wed, 23 Jan 2019 at 18:30, Rowan Collins  wrote:

> On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:
>
> > I understand the rationale for functional programming, may I ask
> > in your opinion should PHP have built-in functions for arithmetic
> > operations so that it can be used in such a way without needing userland
> > implementations?
> >
>
> There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
> Seems like the kind of thing either of them might work on...) to add a
> syntax for using any operator as a callable. I don't think it got beyond a
> thought experiment, but it's an interesting concept, and would
> theoretically remove the need for some of this duplicate functionality.
>

Indeed seems like Andrea Faulds did publish an RFC which is in the
Under discussion section: https://wiki.php.net/rfc/operator_functions

Best regards

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Wed, 23 Jan 2019 at 17:25, Girgias  wrote:

> I understand the rationale for functional programming, may I ask
> in your opinion should PHP have built-in functions for arithmetic
> operations so that it can be used in such a way without needing userland
> implementations?
>


There was a proposal a while ago (Sara Golemon maybe? Or Andrea Faulds?
Seems like the kind of thing either of them might work on...) to add a
syntax for using any operator as a callable. I don't think it got beyond a
thought experiment, but it's an interesting concept, and would
theoretically remove the need for some of this duplicate functionality.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

 On Wed, 23 Jan 2019 at 16:23, Dan Ackroyd  wrote:

> On Tue, 22 Jan 2019 at 20:34, Girgias  wrote:
> >
> >  a list of  functions which seem reasonable to deprecate
>
> > Classes/Objects functions:
> >
> >- is_a (use instanceof operator)
>
> This is a fundamentally bad idea.
>
> Functions can be passed around as functions, operators cannot be,
> which makes it easier to composite functionality together with
> functions than with operators.
>
> The main reason to use operators at all is to improve readability.
> i.e. `$x = $y + 2;` is easier to scan-read than `$x = plus($y, 2);`
> (and I'm not sure the instanceof operator actually achieves this aim.)
> but for when you want to be able to pass a function as a parameter,
> then functions are much more powerful.
>

> The same is true for floatval, intval etc.
>

I understand the rationale for functional programming, may I ask
in your opinion should PHP have built-in functions for arithmetic
operations so that it can be used in such a way without needing userland
implementations?


>
> > Function handling functions:
> >
> >- call_user_func (invoke directly)
> >- call_user_func_array (arguments can be provided with the splat
> >operator (...) as of PHP 5.6
> >- forward_static_call (same reason as call_user_func)
> >- forward_static_cal_array (same reason as call_user_func_array)
> >- func_get_arg (seems unnecessary as of PHP 5.6 with variadic
> functions
> >(splat operator))
> >- func_get_args (same reason as func_get_arg)
> >- func_num_args (same reason as func_get_arg)
>
> btw this RFC https://wiki.php.net/rfc/consistent_callables probably
> needs to be worked on before all the different ways of calling
> 'callables' is interchangeable anyway.
>

Now that's a compelling reason where I can get behind not doing so.


On Wed, 23 Jan 2019 at 17:19, Thomas Hruska  wrote:

> I've run a set of searches against GitHub code repos.
>
> The numbers below are just generic metrics of usage and reloading search
> result pages caused result counts to vary extremely widely.  I didn't
> look too in-depth at each result set beyond getting a number and a
> general feel.
>
>
Cheers for doing this Thomas.

> - func_get_args (same reason as func_get_arg)
>
> https://github.com/search?l=PHP&o=desc&q=func_get_args&s=indexed&type=Code
>
> 9.2 million results.
>
> Oh, and the first search result that turned up for me looks fun:
>
>
> https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8c74110b72f44d564c7/src/GraphJS/Router.php
>
>  self::initSession(...\func_get_args());
>
> An elegant (and yet slightly horrifying) one-liner crushes whatever
> argument you seemed to have about the splat operator:  The author used
> both.
>

Now this is an unexpected result on which I'll see myself beaten.

I'm not in favor of removal of these functions.  While *I* don't use
> them, lots of people still use them in conjunction with array_map() and
> similar callback-oriented functions.  I'd rather see them be optimized
> within specific contexts such as array_map() for significantly improved
> performance *first* before recommending deprecation.
>
>
It has more or less already been established that deprecating those
function is pretty
much impossible in the current state.

> - gettype (more on this later [1])
>
> https://github.com/search?l=PHP&o=desc&q=gettype&s=indexed&type=Code
>
> 9.3 million results.  However, most results seem to be classes with a
> method called getType(), so those again throw off an accurate global count.
>

I remember encountering this issue while I was first writting this email a
month ago and couldn't
get meaningfull results.


> > Maths functions aliases:
> >
> > - getrandmax
>
> Shouldn't that have a comment like "(use mt_getrandmax() instead)"?
>

It should,


> > - rand (use mt_rand instead)
> > - srand (alias of mt_srand as of PHP 7.1)
>
> Most usages from searches seem to be using the mt_...() functions
> already anyway.
>

Good to know

> - is_writeable — Alias of is_writable
>
> https://github.com/search?l=PHP&o=desc&q=is_writeable&s=indexed&type=Code
>
> https://github.com/search?l=PHP&o=desc&q=is_writable&s=indexed&type=Code
>
> 629,500 vs. 3.65 million results.
>
> (On Google:  1.19 million vs. 6.2 million results for the words
> writeable vs. writable.)
>
> Deprecating this alias seems petty.  Users currently don't have to look
> up the function at the moment.  Removing the alias will cause EVERYONE
> to look up the function to be sure they remember how to correctly spell
> it to avoid the deprecation warning.
>

It may same petty but it was just an idea.
Seems like it's to big of a hassle to convert.


> Old signatures:
> >
> > - implode (historical signature)
>
> Impossible to run a search for this.
>

Understandable that this is impossible to search for.


>
> > Controversial idea:
> >
> > - deprecate array function creation (array())
>
> https://github.com/searc

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On Wed, 23 Jan 2019 at 16:37, Benjamin Morel 
wrote:

> > 2.78 million vs. 5.1 million* code references.
> > 1.54 million results.
> > 10 million results.  Broad, active usage.
> > ...
>
> I would not in any way base deprecation decisions on current usage
> statistics. If there are several ways to do something, and one is clearly
> better than the others (naming consistency) then the choice should IMHO be
> imposed to the community.
>

Every time you impose a change on the community, you are costing that
community goodwill, time, and ultimately money. It is absolutely critical
that decisions weigh that cost against the expected benefit.

If the expected benefit is a small increase in readability, and the
expected cost is a huge volume of existing code requiring changes, we
should rule out the change.



> Trying to make 10+ years old codebases work with recent versions of PHP
> without modification slows down development a lot.
> Major versions are here to break things.


No, major versions are here *to improve the language while breaking as
little as possible*. We are not in the business of change for change's
sake; every change needs to be justified, regardless of where in the
release cycle it comes.



> Changelogs and runtime deprecation notices are here to help.
>

As others have pointed out, runtime deprecation notices have a cost on
their own - they create noise in logs, obscuring more important changes,
and taking up disk space. Again, this is a cost that needs to be weighed
against the expected benefit.

Regards,
-- 
Rowan Collins
[IMSoP]

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Benjamin Morel]

> 2.78 million vs. 5.1 million* code references.
> 1.54 million results.
> 10 million results.  Broad, active usage.
> ...

I would not in any way base deprecation decisions on current usage
statistics. If there are several ways to do something, and one is clearly
better than the others (naming consistency) then the choice should IMHO be
imposed to the community.
Trying to make 10+ years old codebases work with recent versions of PHP
without modification slows down development a lot.
Major versions are here to break things. Changelogs and runtime deprecation
notices are here to help.

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Thomas Hruska]

On 1/22/2019 1:34 PM, Girgias wrote:

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:


I've run a set of searches against GitHub code repos.

The numbers below are just generic metrics of usage and reloading search 
result pages caused result counts to vary extremely widely.  I didn't 
look too in-depth at each result set beyond getting a number and a 
general feel.




PHP Info/Option functions:

- php_sapi_name (use PHP_SAPI constant)


https://github.com/search?l=PHP&o=desc&q=php_sapi_name&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=PHP_SAPI&s=indexed&type=Code

1.02 million vs. 2.0 million code references.  Both in active use.



- phpversion (use PHP_VERSION constant)


https://github.com/search?l=PHP&o=desc&q=phpversion&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=PHP_VERSION&s=indexed&type=Code

2.78 million vs. 5.1 million* code references.

* Unfortunately, WordPress uses a variable called $php_version, which 
throws off the global count.


WordPress itself uses phpversion().  That's 30% of all websites.



- php_uname (use PHP_OS constant)


No.  PHP_OS only covers one option that php_uname() exposes.  Simple 
searches are turning up plenty of other php_uname() options in use.




Classes/Objects functions:

- is_a (use instanceof operator)


https://github.com/search?l=PHP&o=desc&q=is_a&s=indexed&type=Code

https://github.com/search?l=PHP&o=desc&q=instanceof&s=indexed&type=Code

1.7 million vs. 28.4 million results.

is_a() is still seeing some use but most people are using instanceof.

Also, $allow_string describes "This also prevents from calling 
autoloader if the class doesn't exist."  No equivalent functionality 
exists without this function.




- is_subclass_of (not exactly what it's purpose is but the instanceof
operator SHOULD be a valid equivalence with another condition if the same
class must not be used)


https://github.com/search?l=PHP&o=desc&q=is_subclass_of&s=indexed&type=Code

1.54 million results.

In addition to the notes above about is_a(), CodeIgniter appears to use 
this function.




Function handling functions:

- call_user_func (invoke directly)


https://github.com/search?l=PHP&o=desc&q=call_user_func&s=indexed&type=Code

10 million results.  Broad, active usage.

Also, there are scenarios where you can't always invoke directly as you 
claim.  Been there, done that myself.



- call_user_func_array (arguments can be provided with the splat
operator (...) as of PHP 5.6


https://github.com/search?l=PHP&o=desc&q=call_user_func_array&s=indexed&type=Code

11.4 million results (and breaks GitHub search for me in a unique way 
I've not seen before).  Broad, active usage.


See above.


- forward_static_call (same reason as call_user_func)


https://github.com/search?l=PHP&o=desc&q=forward_static_call&s=indexed&type=Code

52,200 results.

Can probably be deprecated.


- forward_static_call_array (same reason as call_user_func_array)


https://github.com/search?l=PHP&o=desc&q=forward_static_call_array&s=indexed&type=Code

14,581 results.

Can probably be deprecated.


- func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
(splat operator))


https://github.com/search?l=PHP&o=desc&q=func_get_arg&s=indexed&type=Code

1.1 million results.

While I personally never saw the point of this function since 
func_get_args() exists, func_get_arg() sees regular use.



- func_get_args (same reason as func_get_arg)


https://github.com/search?l=PHP&o=desc&q=func_get_args&s=indexed&type=Code

9.2 million results.

Oh, and the first search result that turned up for me looks fun:

https://github.com/phonetworks/graphjs-server/blob/94d4a672e12a3b0b7626d8c74110b72f44d564c7/src/GraphJS/Router.php

self::initSession(...\func_get_args());

An elegant (and yet slightly horrifying) one-liner crushes whatever 
argument you seemed to have about the splat operator:  The author used both.



- func_num_args (same reason as func_get_arg)


https://github.com/search?l=PHP&o=desc&q=func_num_args&s=indexed&type=Code

3.35 million results.



Variable handling functions:
Aliases:

- is_double


https://github.com/search?l=PHP&o=desc&q=is_double&s=indexed&type=Code

345,700 results.  Seems to be used for unit testing code bits verifying 
return types.



- is_integer


https://github.com/search?l=PHP&o=desc&q=is_integer&s=indexed&type=Code

1 million results.


- is_long


https://github.com/search?l=PHP&o=desc&q=is_long&s=indexed&type=Code

95,400 results.


- is_real (already in the deprecation draft for PHP 7.4)


https://gith

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Levi Morrison]

On Tue, Jan 22, 2019 at 1:35 PM Girgias  wrote:
>
> Greetings PHP internals,
> After skimming through the PHP documentation, I came up with a list of
> functions which seem
> reasonable to deprecate as of PHP 8 and I would like to gather some
> opinions from Internals.
> If this seems like it's too early or should be in an RFC draft please let
> me know and in case it
> needs an RFC may I have Karma to do so.
> Without further ado here is the list I compiled:
>
> PHP Info/Option functions:
>
>- php_sapi_name (use PHP_SAPI constant)
>- phpversion (use PHP_VERSION constant)
>- php_uname (use PHP_OS constant)
>
> Classes/Objects functions:
>
>- is_a (use instanceof operator)
>- is_subclass_of (not exactly what it's purpose is but the instanceof
>operator SHOULD be a valid equivalence with another condition if the same
>class must not be used)
>
> Function handling functions:
>
>- call_user_func (invoke directly)
>- call_user_func_array (arguments can be provided with the splat
>operator (...) as of PHP 5.6
>- forward_static_call (same reason as call_user_func)
>- forward_static_cal_array (same reason as call_user_func_array)
>- func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
>(splat operator))
>- func_get_args (same reason as func_get_arg)
>- func_num_args (same reason as func_get_arg)
>
> Variable handling functions:
> Aliases:
>
>- is_double
>- is_integer
>- is_long
>- is_real (already in the deprecation draft for PHP 7.4)
>
> Setting var type (can use variable casting nowadays):
>
>- boolval
>- doubleval
>- floatval
>- intval (for arbitrary base change there exists the math function
>base_convert)
>- settype
>- strval
>- gettype (more on this later [1])
>
> String functions aliases:
>
>- chop (alias of rtrim)
>- join (alias of implode)
>- strchr (alias of strstr)
>
> Maths functions aliases:
>
>- getrandmax
>- rand (use mt_rand instead)
>- srand (alias of mt_srand as of PHP 7.1)
>
> Filesystem aliases:
>
>- diskfreespace — Alias of disk_free_space
>- fputs —  Alias of fwrite
>- is_writeable — Alias of is_writable
>- set_file_buffer — Alias of stream_set_write_buffer
>
> Old signatures:
>
>- implode (historical signature)
>
> Controversial idea:
>
>- deprecate array function creation (array())
>
>
> [1] About gettype:
> The gettype function is really convenient as it can easily provide the type
> of a variable without
> needed to use a bunch of conditional checks, it can even as of PHP 7.2
> signal if a resource
> has been closed.
> However, it still returns "double" for a float due to historical reasons
> and it seems quite
> complicated to change how it operates currently.
> I have thought of two possible ideas which would allow PHP to return float
> instead of double:
>
> First, create a new reflection class ReflectionVar:
> This feels even to me like a bit of an overkill more so that something
> simple (a unique function
> call) would require an object instantiation. But it can allow some
> extensions such as the
> Reflection for Reference RFC proposed by nikic (c.f.
> https://wiki.php.net/rfc/reference_reflection)
>
> Second, create a new function get_var_type($mixed):
> This would behave exactly the same as the current implementation with the
> one difference that
> it would return 'float' instead of 'double'. This new function name would
> be more consistent with how the other functions are named (namely
> get_resource_type).
> This implementation has the benefit of keeping it simple but will probably
> duplicate code within the engine.
>
>
> Just to remind these are only ideas and feedback is wholeheartedly
> welcomed. I also probably
> missed some more functions which could be deprecated as of PHP 8 but I feel
> this covers
> already a large portion.
>
>
> Best regards
>
> George P. Banyard

I see no reason to get rid of aliases, which comprises most of your list.

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Dan Ackroyd]

On Tue, 22 Jan 2019 at 20:34, Girgias  wrote:
>
>  a list of  functions which seem reasonable to deprecate

> Classes/Objects functions:
>
>- is_a (use instanceof operator)

This is a fundamentally bad idea.

Functions can be passed around as functions, operators cannot be,
which makes it easier to composite functionality together with
functions than with operators.

The main reason to use operators at all is to improve readability.
i.e. `$x = $y + 2;` is easier to scan-read than `$x = plus($y, 2);`
(and I'm not sure the instanceof operator actually achieves this aim.)
but for when you want to be able to pass a function as a parameter,
then functions are much more powerful.

The same is true for floatval, intval etc.

> Function handling functions:
>
>- call_user_func (invoke directly)
>- call_user_func_array (arguments can be provided with the splat
>operator (...) as of PHP 5.6
>- forward_static_call (same reason as call_user_func)
>- forward_static_cal_array (same reason as call_user_func_array)
>- func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
>(splat operator))
>- func_get_args (same reason as func_get_arg)
>- func_num_args (same reason as func_get_arg)

Please no.

You're trying to set your preferred way of doing things as the only
way of doing things. I strongly prefer to use the call_user_func
versions and particularly call_user_func_array as they are clearer
(imo) but also they are easier for people to search online for what
they are doing.

btw this RFC https://wiki.php.net/rfc/consistent_callables probably
needs to be worked on before all the different ways of calling
'callables' is interchangeable anyway.

> Filesystem aliases:
>- is_writeable — Alias of is_writable

Shouldn't we stick with the one that is spelt correctly. /s

Jani wrote:
> The arguments why to deprecate didn't seem much more than, this maybe could be
> deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?

Seconded.

Removing stuff that is working needs to have some justification, such
as removing ongoing maintenance or it's actively harmful, rather than
just we 'can' remove this.

cheers
Dan
Ack

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Wed, 23 Jan 2019 at 15:43, Claude Pache  wrote:

> So, since you didn’t see, here are some practical usages of settype():
>
>  function foo($bar) {
> // $bar is supposed to be either a string, or a list of strings
> settype($bar, 'array');
> // ...
> }
>
> function qux($id) {
>  if (!(is_int($id) || is_string($id) && ctype_digit($id)))
> throw new \TypeError;
> settype($id, 'int');
> // ...
> }
>
> class Foo implements SeekableIterator {
> function seek(/* int */ $position): void {
> // NOTE: we cannot use int typehint here, because PHP7.1 requires
> mixed
> settype($position, 'int');
> // ...
> }
> }
> ?>
>

All these examples could very well use a typecast and or one of the *val
functions


> Here are a usage of settype() with a non-constant second parameter: Define
> a utility function that cast a value to a given type when it is not null:
>
>  function cast_opt($val, $type) {
> if ($val !== null)
> settype($val, $type);
> return $val;
> }
>
> $foo = cast_opt($bar, 'int') // equivalent to: $foo = $bar === null ? null
> : (int) $bar;
> ?>
>
> Sure, one can avoid settype() and do it the complicated way, but why? What
> is the issue with settype(), so that you want to deprecate it?
>

You didn't necessarely need to specify an example with a non-constant
second parameter
because you already gave valid arguments as why not to deprecate it, just
that I didn't see
them. I do appreciate the example however.

Why I want*ed* to deprecate is because I personally didn't see any usage
before,
you provided a valid usage and I don't see the point of deprecating it
anymore.
Maybe that wasn't clear from my previous reply. Because indeed removing
settype
brings back the same issue that I raised with gettype.
As it currently stands the only way I can see how settype can possibly be
deprecated
is ih PHP introduces a ReflectionVar classe which, like said in my initial
email, seems
like total overkill when a simple function exists.


Hope this clears everything up

Best regards

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Claude Pache]

> Le 23 janv. 2019 à 14:19, Girgias  a écrit :
> 
> 
> 
> On Wed, 23 Jan 2019 at 09:19, Claude Pache  wrote:
> 
>> 
>>>  - settype
>> 
>> AFAICS, there is no easy replacement for settype(). If the second argument
>> is a string literal, you can use type coercion + assignment at the price of
>> duplicating the occurrence of the first argument. If the second argument is
>> not known at compile time, you have to resort to a switch statement or
>> something similar.
>> 
> 
> I did not consider that someone might want to set the type of a variable at
> runtime because
> I can not see any pratical usages for that, imho you change a variable type
> into another one
> because you want to work with that specific type. But it basically boils
> down to the same issue
> as with gettype that without it you need to do a switch statement to get
> something similar.
> 
> 

So, since you didn’t see, here are some practical usages of settype():



Here are a usage of settype() with a non-constant second parameter: Define a 
utility function that cast a value to a given type when it is not null:



Sure, one can avoid settype() and do it the complicated way, but why? What is 
the issue with settype(), so that you want to deprecate it?

—Claude


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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

 On Wed, 23 Jan 2019 at 09:02, Markus Fischer  wrote:

> Hi,
>
> On 22.01.19 21:34, Girgias wrote:
> > - phpversion (use PHP_VERSION constant)
>
> The function takes an optional argument `string $extension`, what is the
> replacement for that?
>

Didn 't realise not all of the extensions have a version constant.


> > - intval (for arbitrary base change there exists the math function
> > base_convert)
>
> I've seen and myself use the following construct a lot to "quickly"
> convert data within an array:
>
> $data = array_map('intval', $data);
>
> It's really practical because I don't have to write a (more verbose)
> closure.
>
> I'd argue this applies to the other `*val` calls too.
>

Seems like this is one of the only practical usages but a quite important
one
that I did not consider.

> - join (alias of implode)
> >
> > Old signatures:
> >
> > - implode (historical signature)
>
> Is there a correlation here why you mention the alias join and the
> actual function implode? I hope you would want to leave either in the
> language  :-)
>

Completly unrelated, join is an alias whereas the old implode signature I'm
talking about is the implode(array $pieces, string $glue = '') which is not
recommended
compared to the recommended signature implode(string $glue, array $pieces)
which
mimics the explode signature.
I do want to keep implode() just deprecate the historical signature.

On Wed, 23 Jan 2019 at 09:19, Claude Pache  wrote:

>
> >   - settype
>
> AFAICS, there is no easy replacement for settype(). If the second argument
> is a string literal, you can use type coercion + assignment at the price of
> duplicating the occurrence of the first argument. If the second argument is
> not known at compile time, you have to resort to a switch statement or
> something similar.
>

I did not consider that someone might want to set the type of a variable at
runtime because
I can not see any pratical usages for that, imho you change a variable type
into another one
because you want to work with that specific type. But it basically boils
down to the same issue
as with gettype that without it you need to do a switch statement to get
something similar.


>
> >  - deprecate array function creation (array())
>
> Here, I was really wondering why you didn’t mention function-like
> destructuring as well (list()). (Not that I think it is a good idea.)
>

Thanks for catching that oversight, been a while since I haven't used list()
And I can totally see why you wouldn't think it's a good idea I just feel a
major version change
is an approriate time to bring such controversial issues to the table.

On Wed, 23 Jan 2019 at 11:04, Jani Ollikainen 
wrote:

> Hi,
>
> The arguments why to deprecate didn't seem much more than, this maybe
> could be deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?
>

My reasonning for theses deprecation is to get rid of some of the "clutter"
within the
PHP core, as in I don't see the benefit of having multiple aliases nor
functions which can
be achieved with some more modern constructs.


> But some comments that I didn't notice in others.
>
> >- php_uname (use PHP_OS constant)
>
> PHP_OS is php_uname('s'), how about rest:
>
> mode
>
> mode is a single character that defines what information is returned:
>
> 'a': This is the default. Contains all modes in the sequence "s n
> r v m".
> 's': Operating system name. eg. FreeBSD.
> 'n': Host name. eg. localhost.example.com.
>
gethostname() can retrive this information

> 'r': Release name. eg. 5.1.2-RELEASE.
>
PHP_EXTRA_VERSION

> 'v': Version information. Varies a lot between operating systems.
> 'm': Machine type. eg. i386.
>
For these two doesn't seem like I can find something equivalent

> Classes/Objects functions:
> >   - is_a (use instanceof operator)
>

intanceof accepts a string as secodn operand but it needs to be within a
variable
however contrary to is_subclass_of, is_a does not accept a string as first
parameter
which makes is_a completly unnecessary imho.
See: https://3v4l.org/hn1Ao

>   - is_subclass_of (not exactly what it's purpose is but the instanceof
> >   operator SHOULD be a valid equivalence with another condition if the
> same
> >   class must not be used)
>

I do acknoledge this one has a usage as per one of my previous replies.


> > Function handling functions:
> >   - call_user_func (invoke directly)
>
> Yes, they give a little performance hit, but I still kind of like them.
> Like if we think the following, I think I would prefer call_user_func for
> syntax.
>
> class PREA {
> public function AB() {
> echo "HELLO".PHP_EOL;
> }
> public static function AC() {
> echo "HELLOSTATIC".PHP_EOL;
> }
> }
>
> $prefix='PRE';
> $class='A';
> $method='B';
> $static='C';
>
> $classVar=$prefix.$class;
>
> (new $classVar())->{$class.$method}();

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Arvids Godjuks]

ср, 23 янв. 2019 г. в 12:04, Jani Ollikainen :

> Hi,
>
> The arguments why to deprecate didn't seem much more than, this maybe
> could be deprecated. I think there should usually be some
> benefits of deprecating, otherwise why not just leave it as it is?
>
> But some comments that I didn't notice in others.
>
> >- php_uname (use PHP_OS constant)
>
> PHP_OS is php_uname('s'), how about rest:
>
> mode
>
> mode is a single character that defines what information is returned:
>
> 'a': This is the default. Contains all modes in the sequence "s n
> r v m".
> 's': Operating system name. eg. FreeBSD.
> 'n': Host name. eg. localhost.example.com.
> 'r': Release name. eg. 5.1.2-RELEASE.
> 'v': Version information. Varies a lot between operating systems.
> 'm': Machine type. eg. i386.
>
>
> > Classes/Objects functions:
> >   - is_a (use instanceof operator)
> >   - is_subclass_of (not exactly what it's purpose is but the instanceof
> >   operator SHOULD be a valid equivalence with another condition if the
> same
> >   class must not be used)
>
> Both these have $allow_string
>
> > Function handling functions:
> >   - call_user_func (invoke directly)
>
> Yes, they give a little performance hit, but I still kind of like them.
> Like if we think the following, I think I would prefer call_user_func for
> syntax.
>
> class PREA {
> public function AB() {
> echo "HELLO".PHP_EOL;
> }
> public static function AC() {
> echo "HELLOSTATIC".PHP_EOL;
> }
> }
>
> $prefix='PRE';
> $class='A';
> $method='B';
> $static='C';
>
> $classVar=$prefix.$class;
>
> (new $classVar())->{$class.$method}();
> ($prefix.$class)::{$class.$static}();
>
> call_user_func(array(new $classVar(), $class.$method));
> call_user_func($prefix.$class.'::'.$class.$static);
>
> And for the rest. Yes, there is another way of doing it, but is that
> really enough for deprecating something?
>
> > Setting var type (can use variable casting nowadays):
>
> Yes, we can cast, but is this reason for make someone to go through all
> the old code and do
> -$var = intval($var);
> +$var = (int) $var;
>
>
>
Hello to everyone.

As a userland dev, I have to agree with Jani here - when I looked through
the list of functions I had question marks all over the place about the
`call_user_func*` family. Sure, closures are nice, but as demonstrated
above they are not always the best-looking code and `call_user_func*`
family has it's used. Maybe I'm just not using this functionality that
much, so it seems like it's out of nowhere to deprecate/remove these for me.

is_writeable vs is_writable - the more you know *music* :)


-- 
Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

RE: [PHP-DEV] Deprecation ideas for PHP 8

[Jani Ollikainen]

Hi,

The arguments why to deprecate didn't seem much more than, this maybe could be 
deprecated. I think there should usually be some
benefits of deprecating, otherwise why not just leave it as it is?

But some comments that I didn't notice in others.

>- php_uname (use PHP_OS constant)

PHP_OS is php_uname('s'), how about rest:

mode

mode is a single character that defines what information is returned:

'a': This is the default. Contains all modes in the sequence "s n r v 
m".
's': Operating system name. eg. FreeBSD.
'n': Host name. eg. localhost.example.com.
'r': Release name. eg. 5.1.2-RELEASE.
'v': Version information. Varies a lot between operating systems.
'm': Machine type. eg. i386.


> Classes/Objects functions:
>   - is_a (use instanceof operator)
>   - is_subclass_of (not exactly what it's purpose is but the instanceof
>   operator SHOULD be a valid equivalence with another condition if the same
>   class must not be used)

Both these have $allow_string 

> Function handling functions:
>   - call_user_func (invoke directly)

Yes, they give a little performance hit, but I still kind of like them. Like if 
we think the following, I think I would prefer call_user_func for syntax.

class PREA {
public function AB() {
echo "HELLO".PHP_EOL;
}
public static function AC() {
echo "HELLOSTATIC".PHP_EOL;
}
}

$prefix='PRE';
$class='A';
$method='B';
$static='C';

$classVar=$prefix.$class;

(new $classVar())->{$class.$method}();
($prefix.$class)::{$class.$static}();

call_user_func(array(new $classVar(), $class.$method));
call_user_func($prefix.$class.'::'.$class.$static);

And for the rest. Yes, there is another way of doing it, but is that really 
enough for deprecating something?

> Setting var type (can use variable casting nowadays):

Yes, we can cast, but is this reason for make someone to go through all the old 
code and do
-$var = intval($var);
+$var = (int) $var;

 

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Claude Pache]

>   - settype


AFAICS, there is no easy replacement for settype(). If the second argument is a 
string literal, you can use type coercion + assignment at the price of 
duplicating the occurrence of the first argument. If the second argument is not 
known at compile time, you have to resort to a switch statement or something 
similar.


>  - deprecate array function creation (array())

Here, I was really wondering why you didn’t mention function-like destructuring 
as well (list()). (Not that I think it is a good idea.)

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Markus Fischer]

Hi,

On 22.01.19 21:34, Girgias wrote:

- phpversion (use PHP_VERSION constant)


The function takes an optional argument `string $extension`, what is the 
replacement for that?



- intval (for arbitrary base change there exists the math function
base_convert)


I've seen and myself use the following construct a lot to "quickly" 
convert data within an array:


$data = array_map('intval', $data);

It's really practical because I don't have to write a (more verbose) 
closure.


I'd argue this applies to the other `*val` calls too.


- join (alias of implode)

Old signatures:

- implode (historical signature)


Is there a correlation here why you mention the alias join and the 
actual function implode? I hope you would want to leave either in the 
language  :-)



cheers,
- Markus

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Rowan Collins]

On 22/01/2019 21:27, Midori Koçak wrote:

Can we also add strange function names without any naming conventions to
this list


In short, no. I wish we had an FAQ where we could avoid recapping the 
arguments around this, but it has come up many times, and the conclusion 
has always been that it's never going to happen.


It would be great if we could invent a time machine and design the 
language differently, but it's too late now, there is just too much code 
out there to "fix".


Regards,

--
Rowan Collins
[IMSoP]


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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Tue, 22 Jan 2019 at 23:28, Yasuo Ohgaki  wrote:

> On Wed, Jan 23, 2019 at 7:08 AM Girgias  wrote:
>
> > On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki  wrote:
> >
> >> Hi Girgias
> >>
> >> It seems good list in general.
> >> There would not be issues marking them as deprecated.
> >> "Deprecation" means "Soft deprecation", correct?
> >>
> >> Removing these aliases from PHP 8 is not good idea.
> >> Aliases should be removed when nobody cares about these aliases.
> >>
> >> For example, pg_loopen()/etc were there until nobody cares about these
> >> aliases.
> >> New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
> >> documented since PHP 4.x.
> >>
> >> Regards,
> >>
> >> --
> >> Yasuo Ohgaki
> >> yohg...@ohgaki.net
> >>
> >
> > Hello Yasuo Ohgaki.
> >
> > By Deprecation, I was indeed meaning that as of PHP 8 these function
> > should throw
> > E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
> > time
> > for people to adapt and upgrade their codebase.
> >
>
> This is good approach, too.
> The alias system does not allow to get currently called function name w/o
> overhead, AFAIK. i.e. It simply calls defined functions.
>
> Perhaps, add
>
> PHP_FALIAS_DEPRECATED()
>
> for it.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net


I'm all for it if it reduces overhead.

Best regards

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Yasuo Ohgaki]

On Wed, Jan 23, 2019 at 7:08 AM Girgias  wrote:

> On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki  wrote:
>
>> Hi Girgias
>>
>> It seems good list in general.
>> There would not be issues marking them as deprecated.
>> "Deprecation" means "Soft deprecation", correct?
>>
>> Removing these aliases from PHP 8 is not good idea.
>> Aliases should be removed when nobody cares about these aliases.
>>
>> For example, pg_loopen()/etc were there until nobody cares about these
>> aliases.
>> New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
>> documented since PHP 4.x.
>>
>> Regards,
>>
>> --
>> Yasuo Ohgaki
>> yohg...@ohgaki.net
>>
>
> Hello Yasuo Ohgaki.
>
> By Deprecation, I was indeed meaning that as of PHP 8 these function
> should throw
> E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
> time
> for people to adapt and upgrade their codebase.
>

This is good approach, too.
The alias system does not allow to get currently called function name w/o
overhead, AFAIK. i.e. It simply calls defined functions.

Perhaps, add

PHP_FALIAS_DEPRECATED()

for it.

Regards,

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Tue, 22 Jan 2019 at 22:52, Yasuo Ohgaki  wrote:

> Hi Girgias
>
> It seems good list in general.
> There would not be issues marking them as deprecated.
> "Deprecation" means "Soft deprecation", correct?
>
> Removing these aliases from PHP 8 is not good idea.
> Aliases should be removed when nobody cares about these aliases.
>
> For example, pg_loopen()/etc were there until nobody cares about these
> aliases.
> New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
> documented since PHP 4.x.
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

Hello Yasuo Ohgaki.

By Deprecation, I was indeed meaning that as of PHP 8 these function should
throw
E_DEPRECATED errors and be removed as of PHP 9 which would give plenty of
time
for people to adapt and upgrade their codebase.

Best regards

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Yasuo Ohgaki]

On Wed, Jan 23, 2019 at 6:28 AM Midori Koçak  wrote:

> Can we also add strange function names without any naming conventions to
> this list? Without undersore: strcspn, With underscore:  str_repeat, chain
> of abrevs: strnatcasecmp. Similar namings do exist for array functions
> either.
>

Candidates are these
https://wiki.php.net/rfc/consistent_function_names

>From previous discussion, I think it would be better to keep both PHP and
POSIX names.

Regards,

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Yasuo Ohgaki]

Hi Girgias

It seems good list in general.
There would not be issues marking them as deprecated.
"Deprecation" means "Soft deprecation", correct?

Removing these aliases from PHP 8 is not good idea.
Aliases should be removed when nobody cares about these aliases.

For example, pg_loopen()/etc were there until nobody cares about these
aliases.
New names, pg_lo_open()/etc, were given in PHP4.x. These changes were
documented since PHP 4.x.

Regards,

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

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Midori Koçak]

Can we also add strange function names without any naming conventions to
this list? Without undersore: strcspn, With underscore:  str_repeat, chain
of abrevs: strnatcasecmp. Similar namings do exist for array functions
either.

Cheers,
Midori

On Tue, 22 Jan 2019 at 22:22, Girgias  wrote:

> On Tue, 22 Jan 2019 at 21:48, Stephen Reay 
> wrote:
>
> >
> > > On 23 Jan 2019, at 03:34, Girgias  wrote:
> > > Classes/Objects functions:
> > >
> > >   - is_a (use instanceof operator)
> > >   - is_subclass_of (not exactly what it's purpose is but the instanceof
> > >   operator SHOULD be a valid equivalence with another condition if the
> > same
> > >   class must not be used)
> >
> > is_subclass_of allows checking string class names, instanceof (AFAIK)
> does
> > not.
> >
>
> Good catch, just checked and it's indead the case that instanceof can't
> check string class names:
> https://3v4l.org/DkMC4
>
> George P. Banyard
>

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

On Tue, 22 Jan 2019 at 21:48, Stephen Reay  wrote:

>
> > On 23 Jan 2019, at 03:34, Girgias  wrote:
> > Classes/Objects functions:
> >
> >   - is_a (use instanceof operator)
> >   - is_subclass_of (not exactly what it's purpose is but the instanceof
> >   operator SHOULD be a valid equivalence with another condition if the
> same
> >   class must not be used)
>
> is_subclass_of allows checking string class names, instanceof (AFAIK) does
> not.
>

Good catch, just checked and it's indead the case that instanceof can't
check string class names:
https://3v4l.org/DkMC4

George P. Banyard

Re: [PHP-DEV] Deprecation ideas for PHP 8

[Stephen Reay]

> On 23 Jan 2019, at 03:34, Girgias  wrote:
> 
> Greetings PHP internals,
> After skimming through the PHP documentation, I came up with a list of
> functions which seem
> reasonable to deprecate as of PHP 8 and I would like to gather some
> opinions from Internals.
> If this seems like it's too early or should be in an RFC draft please let
> me know and in case it
> needs an RFC may I have Karma to do so.
> Without further ado here is the list I compiled:
> 
> PHP Info/Option functions:
> 
>   - php_sapi_name (use PHP_SAPI constant)
>   - phpversion (use PHP_VERSION constant)
>   - php_uname (use PHP_OS constant)
> 
> Classes/Objects functions:
> 
>   - is_a (use instanceof operator)
>   - is_subclass_of (not exactly what it's purpose is but the instanceof
>   operator SHOULD be a valid equivalence with another condition if the same
>   class must not be used)
> 
> Function handling functions:
> 
>   - call_user_func (invoke directly)
>   - call_user_func_array (arguments can be provided with the splat
>   operator (...) as of PHP 5.6
>   - forward_static_call (same reason as call_user_func)
>   - forward_static_cal_array (same reason as call_user_func_array)
>   - func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
>   (splat operator))
>   - func_get_args (same reason as func_get_arg)
>   - func_num_args (same reason as func_get_arg)
> 
> Variable handling functions:
> Aliases:
> 
>   - is_double
>   - is_integer
>   - is_long
>   - is_real (already in the deprecation draft for PHP 7.4)
> 
> Setting var type (can use variable casting nowadays):
> 
>   - boolval
>   - doubleval
>   - floatval
>   - intval (for arbitrary base change there exists the math function
>   base_convert)
>   - settype
>   - strval
>   - gettype (more on this later [1])
> 
> String functions aliases:
> 
>   - chop (alias of rtrim)
>   - join (alias of implode)
>   - strchr (alias of strstr)
> 
> Maths functions aliases:
> 
>   - getrandmax
>   - rand (use mt_rand instead)
>   - srand (alias of mt_srand as of PHP 7.1)
> 
> Filesystem aliases:
> 
>   - diskfreespace — Alias of disk_free_space
>   - fputs —  Alias of fwrite
>   - is_writeable — Alias of is_writable
>   - set_file_buffer — Alias of stream_set_write_buffer
> 
> Old signatures:
> 
>   - implode (historical signature)
> 
> Controversial idea:
> 
>   - deprecate array function creation (array())
> 
> 
> [1] About gettype:
> The gettype function is really convenient as it can easily provide the type
> of a variable without
> needed to use a bunch of conditional checks, it can even as of PHP 7.2
> signal if a resource
> has been closed.
> However, it still returns "double" for a float due to historical reasons
> and it seems quite
> complicated to change how it operates currently.
> I have thought of two possible ideas which would allow PHP to return float
> instead of double:
> 
> First, create a new reflection class ReflectionVar:
> This feels even to me like a bit of an overkill more so that something
> simple (a unique function
> call) would require an object instantiation. But it can allow some
> extensions such as the
> Reflection for Reference RFC proposed by nikic (c.f.
> https://wiki.php.net/rfc/reference_reflection)
> 
> Second, create a new function get_var_type($mixed):
> This would behave exactly the same as the current implementation with the
> one difference that
> it would return 'float' instead of 'double'. This new function name would
> be more consistent with how the other functions are named (namely
> get_resource_type).
> This implementation has the benefit of keeping it simple but will probably
> duplicate code within the engine.
> 
> 
> Just to remind these are only ideas and feedback is wholeheartedly
> welcomed. I also probably
> missed some more functions which could be deprecated as of PHP 8 but I feel
> this covers
> already a large portion.
> 
> 
> Best regards
> 
> George P. Banyard

is_subclass_of allows checking string class names, instanceof (AFAIK) does not.



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

[PHP-DEV] Deprecation ideas for PHP 8

[Girgias]

Greetings PHP internals,
After skimming through the PHP documentation, I came up with a list of
functions which seem
reasonable to deprecate as of PHP 8 and I would like to gather some
opinions from Internals.
If this seems like it's too early or should be in an RFC draft please let
me know and in case it
needs an RFC may I have Karma to do so.
Without further ado here is the list I compiled:

PHP Info/Option functions:

   - php_sapi_name (use PHP_SAPI constant)
   - phpversion (use PHP_VERSION constant)
   - php_uname (use PHP_OS constant)

Classes/Objects functions:

   - is_a (use instanceof operator)
   - is_subclass_of (not exactly what it's purpose is but the instanceof
   operator SHOULD be a valid equivalence with another condition if the same
   class must not be used)

Function handling functions:

   - call_user_func (invoke directly)
   - call_user_func_array (arguments can be provided with the splat
   operator (...) as of PHP 5.6
   - forward_static_call (same reason as call_user_func)
   - forward_static_cal_array (same reason as call_user_func_array)
   - func_get_arg (seems unnecessary as of PHP 5.6 with variadic functions
   (splat operator))
   - func_get_args (same reason as func_get_arg)
   - func_num_args (same reason as func_get_arg)

Variable handling functions:
Aliases:

   - is_double
   - is_integer
   - is_long
   - is_real (already in the deprecation draft for PHP 7.4)

Setting var type (can use variable casting nowadays):

   - boolval
   - doubleval
   - floatval
   - intval (for arbitrary base change there exists the math function
   base_convert)
   - settype
   - strval
   - gettype (more on this later [1])

String functions aliases:

   - chop (alias of rtrim)
   - join (alias of implode)
   - strchr (alias of strstr)

Maths functions aliases:

   - getrandmax
   - rand (use mt_rand instead)
   - srand (alias of mt_srand as of PHP 7.1)

Filesystem aliases:

   - diskfreespace — Alias of disk_free_space
   - fputs —  Alias of fwrite
   - is_writeable — Alias of is_writable
   - set_file_buffer — Alias of stream_set_write_buffer

Old signatures:

   - implode (historical signature)

Controversial idea:

   - deprecate array function creation (array())


[1] About gettype:
The gettype function is really convenient as it can easily provide the type
of a variable without
needed to use a bunch of conditional checks, it can even as of PHP 7.2
signal if a resource
has been closed.
However, it still returns "double" for a float due to historical reasons
and it seems quite
complicated to change how it operates currently.
I have thought of two possible ideas which would allow PHP to return float
instead of double:

First, create a new reflection class ReflectionVar:
This feels even to me like a bit of an overkill more so that something
simple (a unique function
call) would require an object instantiation. But it can allow some
extensions such as the
Reflection for Reference RFC proposed by nikic (c.f.
https://wiki.php.net/rfc/reference_reflection)

Second, create a new function get_var_type($mixed):
This would behave exactly the same as the current implementation with the
one difference that
it would return 'float' instead of 'double'. This new function name would
be more consistent with how the other functions are named (namely
get_resource_type).
This implementation has the benefit of keeping it simple but will probably
duplicate code within the engine.


Just to remind these are only ideas and feedback is wholeheartedly
welcomed. I also probably
missed some more functions which could be deprecated as of PHP 8 but I feel
this covers
already a large portion.


Best regards

George P. Banyard