Welcome! Log In Create A New Profile

Advanced

[PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope

Posted by Wes 
Hello PHPeople. I just published the RFC "Deprecation of fallback to root
scope".

It is quite a substantial change, but as you can read in the RFC, can be a
(basically) transparent one.
I'm referring to the possibility to shim it in userland. Essentially, this
would move the feature from core to userland.

I hope you like it. Let me know what you think.

https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
Overall, huge improvement, and also simplifies things quite a lot from a
developer PoV by requiring to add explicit references, so this is 100%
thumbs up.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

On Sat, Feb 3, 2018 at 9:27 AM, Wes <[email protected]> wrote:

> Hello PHPeople. I just published the RFC "Deprecation of fallback to root
> scope".
>
> It is quite a substantial change, but as you can read in the RFC, can be a
> (basically) transparent one.
> I'm referring to the possibility to shim it in userland. Essentially, this
> would move the feature from core to userland.
>
> I hope you like it. Let me know what you think.
>
> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>
I get that people want to do that, it's so comfortable. But is it really a
good idea? When I have that kind of problem, I use:

class Foo{
protected $date = "date";
function getDate(){
return ($this->date)();
}
}

$mockFoo = new class extends Foo{ protected $date = "my_fake_date"; };

Or dependency injection (I inject the function as closure in the ctor).
Alternatively, you could consider using https://github.com/krakjoe/uopz
which allows to redefine functions at runtime.
+1

Why should it emit an E_NOTICE instead of E_DEPRECATED?

The code for the shim should probably use define() for constants instead of
eval().

Regards, Niklas
No idea, I'm not really sure what's the difference between E_STRICT and
E_DEPRECATED.
Yeah the shim is just a rough POC (completely forgot that define() can
define in namespaces).
Nicolas Grekas on twitter also suggested that we should introduce
function_alias() that works like class_alias().
With that the shim would be literally a couple of lines long.
question was:
> Do I get that right that it will then no longer be possible to mock
functions from the root namespace during tests?
> At least when the functions are "use"d or are explicitly namespaced...
> Being able to mock functions like "date" or "time" or "mt_rand" is
currently extremely helpful.
On Sat, Feb 3, 2018 at 1:15 PM, Wes <[email protected]> wrote:

> question was:
> > Do I get that right that it will then no longer be possible to mock
> functions from the root namespace during tests?
> > At least when the functions are "use"d or are explicitly namespaced...
> > Being able to mock functions like "date" or "time" or "mt_rand" is
> currently extremely helpful.
>

I think there's something quite broken with the current approach in mocking
core functions, specifically because already having them hardcoded in your
codebase means that the code relies on hidden shared global state.

Can strongly suggest injecting a `Clock` object as is done in
https://github.com/lcobucci/clock, for example.

Same goes for sources of randomness.


Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
On Sat, Feb 3, 2018 at 3:22 AM, Wes <[email protected]> wrote:
> No idea, I'm not really sure what's the difference between E_STRICT and
> E_DEPRECATED.
> Yeah the shim is just a rough POC (completely forgot that define() can
> define in namespaces).
> Nicolas Grekas on twitter also suggested that we should introduce
> function_alias() that works like class_alias().
> With that the shim would be literally a couple of lines long.

From our manual:

> E_NOTICE : Run-time notices. Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.
> E_DEPRECATED: Run-time notices. Enable this to receive warnings about code that will not work in future versions.
> E_STRICT: Enable to have PHP suggest changes to your code which will ensure the best interoperability and forward compatibility of your code.

In my opinion we should emit E_STRICT until we know when the feature
will be removed. At that point we can promote it to E_DEPRECATED and
specifically cite when it will be removed. In any case, E_NOTICE does
not seem appropriate.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2018-02-03 6:27 GMT-02:00 Wes <[email protected]>:

> Hello PHPeople. I just published the RFC "Deprecation of fallback to root
> scope".
>
> It is quite a substantial change, but as you can read in the RFC, can be a
> (basically) transparent one.
> I'm referring to the possibility to shim it in userland. Essentially, this
> would move the feature from core to userland.
>
> I hope you like it. Let me know what you think.
>
> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>
>
>
Personally, I'm a +1 on this. I just can't see a 3/2 majority voting yes on
this proposal. But the odds could be a little better with
a "batteries included" RFC offering a tool to automatically update code by
adding the necessary use statements for core functions,
constants, and classes.

Good luck,
Márcio Almada

https://github.com/marcioAlmada
2018-02-03 14:46 GMT-02:00 Marcio Almada <[email protected]>:

>
> 2018-02-03 6:27 GMT-02:00 Wes <[email protected]>:
>
>> Hello PHPeople. I just published the RFC "Deprecation of fallback to root
>> scope".
>>
>> It is quite a substantial change, but as you can read in the RFC, can be a
>> (basically) transparent one.
>> I'm referring to the possibility to shim it in userland. Essentially, this
>> would move the feature from core to userland.
>>
>> I hope you like it. Let me know what you think.
>>
>> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>>
>>
>>
> Personally, I'm a +1 on this. I just can't see a 3/2 majority voting yes
> on this proposal. But the odds could be a little better with
> a "batteries included" RFC offering a tool to automatically update code by
> adding the necessary use statements for core functions,
> constants, and classes.
>
> Good luck,
> Márcio Almada
>
> https://github.com/marcioAlmada
>
> Heh, I meant 2/3 of course :x
On Sat, Feb 3, 2018 at 11:31 AM, Levi Morrison <[email protected]> wrote:
> In my opinion we should emit E_STRICT until we know when the feature
> will be removed. At that point we can promote it to E_DEPRECATED and
> specifically cite when it will be removed. In any case, E_NOTICE does
> not seem appropriate.
>
I like the three phase approach. Gives frameworks/libraries/users
ridiculous amounts of time to clean up their code, the route to clean
code is clear and the updates are scriptable (I'll bet PHPCS can do
this already), and at the end, we'll be able to have a better engine
and make certain assumptions in the optimizer.

+1
-Sara

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Feb 3, 2018, at 11:04 AM, Sara Golemon <[email protected]> wrote:
>>
> I like the three phase approach. Gives frameworks/libraries/users
> ridiculous amounts of time to clean up their code, the route to clean
> code is clear and the updates are scriptable (I'll bet PHPCS can do
> this already), and at the end, we'll be able to have a better engine
> and make certain assumptions in the optimizer.

Yep, PHP-CS-Fixer can do this, see the native_function_invocation option.

I also like the three phase approach and would be excited to see the possibility for function autoloading and further optimizations.

+1

Aaron Piotrowski
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I just want to add: vote is not very obvious - non internals people are
getting too excited about this :P Please consider:

People that don't have an IDE that handles the imports automatically, will
be effectively forced to prefix \ to everything, which is really ugly.

But again, prefixing \ is not even the end of the world. I bet that if
fallback to global scope didn't exist from the beginning, we wouldn't care
anymore about prefixing \.

PHP has tons of global symbols, it's not like other languages that have
functions organized in classes.
Doing the most basic array and string operations will easily require 4-5
imports, probably more. If all I had to do was `use String;` and all the
string functions were available as methods on strings, then it would be
completely fine.

On the other hand, string functions are rarely used, and arrays can be
replaced by oop collections like spl, ds, or even userland ones.

Function autoloading is almost a development feature only, since in a few
years we'll all likely use opcache, which doesn't need autoloading.
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 04, 2018 10:10AM
Hi!

> I hope you like it. Let me know what you think.
>
> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation

I do not see how this makes sense. This RFC claims there's no BC
breakage, while it deprecates one of the most widely used functions of
the language (using unqualified global functions from inside namespaces)
and adds warnings which will break a lot of existing code (and yes,
notice and warning are basically the same).

I do not see how it makes sense to force people to use \strlen
everywhere (since most of the code in large apps uses namespaces now)
for a tiny and rare possibility that someone would override strlen.
Unless I serously misunderstand what this RFC is proposing, I am
absolutely against it and think doing something like this would be
harmful to PHP. Am I missing something here?
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 3 February 2018 08:27:18 GMT+00:00, Wes <[email protected]> wrote:
>Hello PHPeople. I just published the RFC "Deprecation of fallback to
>root
>scope".
>
>It is quite a substantial change, but as you can read in the RFC, can
>be a
>(basically) transparent one.
>I'm referring to the possibility to shim it in userland.

I'm torn on this one. On the one hand, I think in hindsight this is how functions in namespaces should have worked when they were introduced in PHP 6, I mean 5.3. \foo isn't the prettiest syntax, but people soon got used to writing class names that way, including built in ones like \DateTime. It would make function autoloading simpler, lead to less ambiguous code, and make namespaces work consistently across token types, rather than one way for classes and a different way for functions and constants.

On the other hand, the BC break of moving to that now (or committing ourselves to in the future) is significant, and even raising a notice of whatever level could be highly disruptive. A lot of code bases will issue this message hundreds or thousands of times; I wouldn't be surprised if just the code to format the string and pass it to an active error handler might result in a measurable performance impact in some cases. Crucially, the proposed shim can't actually be written yet, so the only way to suppress these notices will be to edit every single source file, which even if perfectly automated creates a lot of noise in version control.

I think some less invasive way would need to be found to make existing code run the same way, without notices, before and after the change. For instance, if you could opt into the old behaviour by writing "import global functions" at the top of a file, or opt into the new behaviour by writing "namespace only Foo", or since autoloading is a key benefit, "namespace Foo with autoload". It wouldn't be ideal, because it means the engine has to support both modes, but it would be far less painful than adding \ into thousands of lines of existing code.

Regards,

--
Rowan Collins
[IMSoP]

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sat, Feb 3, 2018 at 9:27 AM, Wes <[email protected]> wrote:

> Hello PHPeople. I just published the RFC "Deprecation of fallback to root
> scope".
>
> It is quite a substantial change, but as you can read in the RFC, can be a
> (basically) transparent one.
> I'm referring to the possibility to shim it in userland. Essentially, this
> would move the feature from core to userland.
>
> I hope you like it. Let me know what you think.
>
> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation


To get the same benefits (jit and such) wouldn't it be better to introduce
a "use function root;" or similar statement or a declare() to specify this
file imports all root functions?

I am with stas that this will go towards a huge BC break if the deprecation
was acted on at any time in the future. and in addition people will silence
the notices on global error reporting level, because violations would
happen on a massive scale, inclusing the cost of them being raised dragging
performance down. This will be a problem since other notices will go
unnoticed.
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 04, 2018 11:00PM
Hi!

> To get the same benefits (jit and such) wouldn't it be better to introduce
> a "use function root;" or similar statement or a declare() to specify this
> file imports all root functions?

We already have this right now, and realistically speaking, who wouldn't
do that in their code instead of writing weird \strlen() code? Everybody
would configure their IDEs and so to insert this automatically. So we're
talking about RFC to make people work harder for what they already have
now and then end up in the same place we are already right now.

> was acted on at any time in the future. and in addition people will silence
> the notices on global error reporting level, because violations would

And note also that we can't silence just this warning. Which means
people would have to silence *all* warnings, thus making all other
messages useless. This is not a good development and this is not what we
should be training users to do - saying "well, it's a warning, just
silence it" is the worth idea we could have. If we create a warning,
recommendation should be "it's important enough so we call your
attention to it, please deal with it", not "just silence it". If it's OK
in most cases (as opposed to rare exceptional cases) for it to be
silenced, it shouldn't be there in the first place.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Sun, Feb 4, 2018 at 2:56 PM, Stanislav Malyshev <[email protected]> wrote:
> Hi!
>
>> To get the same benefits (jit and such) wouldn't it be better to introduce
>> a "use function root;" or similar statement or a declare() to specify this
>> file imports all root functions?
>
> We already have this right now, and realistically speaking, who wouldn't
> do that in their code instead of writing weird \strlen() code? Everybody
> would configure their IDEs and so to insert this automatically. So we're
> talking about RFC to make people work harder for what they already have
> now and then end up in the same place we are already right now.

I agree with Stas that this "use function root;" or whatever is pointless.

>> was acted on at any time in the future. and in addition people will silence
>> the notices on global error reporting level, because violations would
>
> And note also that we can't silence just this warning. Which means
> people would have to silence *all* warnings, thus making all other
> messages useless. This is not a good development and this is not what we
> should be training users to do - saying "well, it's a warning, just
> silence it" is the worth idea we could have. If we create a warning,
> recommendation should be "it's important enough so we call your
> attention to it, please deal with it", not "just silence it". If it's OK
> in most cases (as opposed to rare exceptional cases) for it to be
> silenced, it shouldn't be there in the first place.

We have nearly zero E_STRICT warnings right now. Simply configure your
error reporting level to omit E_STRICT if you don't want them. You are
blowing this out of proportion.

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

Thank you for the RFC. I really appreciate it, for sure, but I would
like to raise a concern regarding the atoum test framework [1].

atoum provides 3 mock engines, resp. for class-like entitites,
functions, and constants.

The function and constant mock engines are both based on the same
principle, i.e. it relies on the “entity bubble look up resolution”
algorithm to mock functions or constants. Typically, one might mock the
`file_exists` function like this: `$this->function->file_exists =
function (…) { … };`. In this case, atoum creates a new `file_exists`
function in the same namespace than the system under test (if testing
`A\B\C`, then atoum creates `A\B\file_exists`).

It is a very convinient and beloved way to mock functions and constants.

And thus, this RFC raises the following issue: *This feature is used a
lot by atoum users. The RFC will destroy this feature. It's not about
atoum loosing a master feature, it's more about: How users will be able
to mock functions and constants after that? This is an important question*.

That's a hard question to answer, I know, but in its actual form, the
RFC breaks a non-negligeable part of the testing ecosystem. This is
something to take into account :-).

It is still possible to use moles instead of mocks to achieve the same
behavior, but restricted to user-defined functions only. Moles do not
allow to change the behavior of “VM-defined” functions.

Regards.


[1] http://atoum.org/

On 03.02.18 09:27, Wes wrote:
> Hello PHPeople. I just published the RFC "Deprecation of fallback to root
> scope".
>
> It is quite a substantial change, but as you can read in the RFC, can be a
> (basically) transparent one.
> I'm referring to the possibility to shim it in userland. Essentially, this
> would move the feature from core to userland.
>
> I hope you like it. Let me know what you think.
>
> https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>

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

On 5 Feb 2018 11:18, "Ivan Enderlin" <[email protected]> wrote:

Hello :-),

Thank you for the RFC. I really appreciate it, for sure, but I would like
to raise a concern regarding the atoum test framework [1].

atoum provides 3 mock engines, resp. for class-like entitites, functions,
and constants.

The function and constant mock engines are both based on the same
principle, i.e. it relies on the “entity bubble look up resolution”
algorithm to mock functions or constants. Typically, one might mock the
`file_exists` function like this: `$this->function->file_exists = function
(…) { … };`. In this case, atoum creates a new `file_exists` function in
the same namespace than the system under test (if testing `A\B\C`, then
atoum creates `A\B\file_exists`).

It is a very convinient and beloved way to mock functions and constants.

And thus, this RFC raises the following issue: *This feature is used a lot
by atoum users. The RFC will destroy this feature. It's not about atoum
loosing a master feature, it's more about: How users will be able to mock
functions and constants after that? This is an important question*.

That's a hard question to answer, I know, but in its actual form, the RFC
breaks a non-negligeable part of the testing ecosystem. This is something
to take into account :-).

It is still possible to use moles instead of mocks to achieve the same
behavior, but restricted to user-defined functions only. Moles do not allow
to change the behavior of “VM-defined” functions.

Regards.


[1] http://atoum.org/


See https://externals.io/message/101745#101752

The problem is always with routines (not functions)) that rely on shared
global mutable state.

Mocking those is generally a problem, as it exposes a dependency inversion
issue, rather than actually getting rid of an implicit reliance on global
state that is not declared to consumers of a SUT.
On 5 February 2018 at 10:53, Marco Pivetta <[email protected]> wrote:

>
> See https://externals.io/message/101745#101752
>
> The problem is always with routines (not functions)) that rely on shared
> global mutable state.
>
> Mocking those is generally a problem, as it exposes a dependency inversion
> issue, rather than actually getting rid of an implicit reliance on global
> state that is not declared to consumers of a SUT.
>

While that would be a perfectly fine justification for not adding this
feature, it doesn't address the impact of removing the feature now that it
has existed for over 8 years. Even before the feature is actually removed,
anyone using such tests would be faced with the following options:

* Put up with hundreds of notices until they have a chance to completely
refactor the code in question.
* Suppress all messages of a particular level (possibly E_STRICT initially
and E_DEPRECATED later) until they have the chance to refactor.
* Prepend \ to global function references, purely to stop the deprecation
notices, and break all tests that relied on this mocking mechanism.

None of these options is particularly appealing, and this will all be for a
hypothetical future improvement to the language.

Regards,
--
Rowan Collins
[IMSoP]
On Mon, Feb 5, 2018 at 1:52 PM, Rowan Collins <[email protected]>
wrote:

> None of these options is particularly appealing, and this will all be for a
> hypothetical future improvement to the language.
>

Would proposing a function autoloading RFC together with this improve the
situation?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
On 5 February 2018 at 12:54, Marco Pivetta <[email protected]> wrote:

> On Mon, Feb 5, 2018 at 1:52 PM, Rowan Collins <[email protected]>
> wrote:
>
>> None of these options is particularly appealing, and this will all be for
>> a
>> hypothetical future improvement to the language.
>>
>
> Would proposing a function autoloading RFC together with this improve the
> situation?
>

I think it would, firstly because it gives a visible benefit to the change
we would be asking users to make, and secondly because it allows a shim
like the example in the RFC to be used immediately as a transition.

As I mentioned in an aside previously, it would also make an opt-in
statement more reasonable, because saying "namespace Foo\Bar with autoload"
could both turn off the fallback lookup and turn on autoloading functions
in the current namespace. Fully-qualified function names could be
autoloaded in both modes, and presumably functions explicitly imported with
"use" could be too.

Regards,
--
Rowan Collins
[IMSoP]
Christoph M. Becker
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 05, 2018 03:20PM
On 04.02.2018 at 22:56, Stanislav Malyshev wrote:

>> To get the same benefits (jit and such) wouldn't it be better to introduce
>> a "use function root;" or similar statement or a declare() to specify this
>> file imports all root functions?
>
> We already have this right now, […]

Do we? AFAIK, it is not possible to import *all* functions (or even all
symbols, for that matter) of a namespace, without explicitly mentioning
them.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
May I propose a compromise?

If I understand what I've read over, the default of functions and constants
to global scope is the primary blocking issue for creating an autoloader
for these elements. Where that not PHP's behavior this functionality could
have been implemented by now.

The problem is that behavior has been around so long that any attempt to
change it would incur a massive amount of changes. Using the E_STRICT
notice level instead of E_DEPRECATED has been floated as one fix for this,
but this doesn't change the fact that major applications and frameworks,
such as Drupal, pride themselves in being able to pass all tests even with
E_STRICT enabled. The maintainers of these projects would be annoyed to say
the least to need to fix thousands of lines of code to get back to that
point, and downstream projects such as Drupal could end up waiting years
for all their upstream libraries to get their act together.

Since the two issues are somewhat tied, why not bind them to a
configuration flag following the pattern that was used to ultimately remove
register_globals functionality from the language? At this point let it be
known that when constant/function overloaders hit a php.ini config option
will be added to turn them on -- and turning them on will turn global
scoping for functions off.

This solution isn't perfect. From where Drupal stands, even if all it's
own code stopped using global functions the packages it relies on likely
will continue to do so for some time. Even if they don't, there may be
compatibility issues with the newer version.

A slightly better solution would be to allow this to be set on a per
namespace basis, but as PHP has no true notion of a namespace I don't think
this can be implemented. The declare() statement might allow it to be done
on a per file basis, but that's going to get messy fast.

Still, I feel it is a workable approach despite the drawbacks. If anything
this problem highlights another problem elsewhere in PHP - the inability to
isolate package configuration, or configure packages at all. But that's a
topic for another RFC, one I won't be starting cause I have no idea how to
fix it.

On Mon, Feb 5, 2018 at 8:09 AM, Christoph M. Becker <[email protected]>
wrote:

> On 04.02.2018 at 22:56, Stanislav Malyshev wrote:
>
> >> To get the same benefits (jit and such) wouldn't it be better to
> introduce
> >> a "use function root;" or similar statement or a declare() to specify
> this
> >> file imports all root functions?
> >
> > We already have this right now, […]
>
> Do we? AFAIK, it is not possible to import *all* functions (or even all
> symbols, for that matter) of a namespace, without explicitly mentioning
> them.
>
> --
> Christoph M. Becker
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <[email protected]> wrote:

> The problem is that behavior has been around so long that any attempt to
> change it would incur a massive amount of changes. Using the E_STRICT
> notice level instead of E_DEPRECATED has been floated as one fix for this,
> but this doesn't change the fact that major applications and frameworks,
> such as Drupal, pride themselves in being able to pass all tests even with
> E_STRICT enabled. The maintainers of these projects would be annoyed to say
> the least to need to fix thousands of lines of code to get back to that
> point, and downstream projects such as Drupal could end up waiting years
> for all their upstream libraries to get their act together.
>

Much like any upgrade requiring patches for full compliance with newer PHP
versions, it needs work.

The typical workflow is:

* add PHP.NEXT to the CI setup
* run everything through the tests again, figure out how much has broken
* fix it

In this case, we even *already* have *multiple* tools that automatically
fix this problem in one shot.

Since the two issues are somewhat tied, why not bind them to a
> configuration flag following the pattern that was used to ultimately remove
> register_globals functionality from the language? At this point let it be
> known that when constant/function overloaders hit a php.ini config option
> will be added to turn them on -- and turning them on will turn global
> scoping for functions off.
>

Argh



Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta <[email protected]> wrote:

>
> On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <[email protected]> wrote:
>
>> The problem is that behavior has been around so long that any attempt to
>> change it would incur a massive amount of changes. Using the E_STRICT
>> notice level instead of E_DEPRECATED has been floated as one fix for this,
>> but this doesn't change the fact that major applications and frameworks,
>> such as Drupal, pride themselves in being able to pass all tests even with
>> E_STRICT enabled. The maintainers of these projects would be annoyed to
>> say
>> the least to need to fix thousands of lines of code to get back to that
>> point, and downstream projects such as Drupal could end up waiting years
>> for all their upstream libraries to get their act together.
>>
>
> Much like any upgrade requiring patches for full compliance with newer
> PHP versions, it needs work.
>
> The typical workflow is:
>
> * add PHP.NEXT to the CI setup
> * run everything through the tests again, figure out how much has broken
> * fix it
>
> In this case, we even *already* have *multiple* tools that automatically
> fix this problem in one shot.
>
> Since the two issues are somewhat tied, why not bind them to a
>> configuration flag following the pattern that was used to ultimately
>> remove
>> register_globals functionality from the language? At this point let it be
>> known that when constant/function overloaders hit a php.ini config option
>> will be added to turn them on -- and turning them on will turn global
>> scoping for functions off.
>>
>
> Argh
>
>
Agreed, but you can't just pull the rug out from under people. It's
painful, but it's better to let people opt in to such a major change than
to "break" their code.



>
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
On Mon, Feb 5, 2018 at 3:39 PM, Michael Morris <[email protected]> wrote:

>
>
> On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta <[email protected]> wrote:
>
>>
>> On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris <[email protected]>
>> wrote:
>>
>>> The problem is that behavior has been around so long that any attempt to
>>> change it would incur a massive amount of changes. Using the E_STRICT
>>> notice level instead of E_DEPRECATED has been floated as one fix for
>>> this,
>>> but this doesn't change the fact that major applications and frameworks,
>>> such as Drupal, pride themselves in being able to pass all tests even
>>> with
>>> E_STRICT enabled. The maintainers of these projects would be annoyed to
>>> say
>>> the least to need to fix thousands of lines of code to get back to that
>>> point, and downstream projects such as Drupal could end up waiting years
>>> for all their upstream libraries to get their act together.
>>>
>>
>> Much like any upgrade requiring patches for full compliance with newer
>> PHP versions, it needs work.
>>
>> The typical workflow is:
>>
>> * add PHP.NEXT to the CI setup
>> * run everything through the tests again, figure out how much has broken
>> * fix it
>>
>> In this case, we even *already* have *multiple* tools that automatically
>> fix this problem in one shot.
>>
>> Since the two issues are somewhat tied, why not bind them to a
>>> configuration flag following the pattern that was used to ultimately
>>> remove
>>> register_globals functionality from the language? At this point let it
>>> be
>>> known that when constant/function overloaders hit a php.ini config option
>>> will be added to turn them on -- and turning them on will turn global
>>> scoping for functions off.
>>>
>>
>> Argh
>>
>>
> Agreed, but you can't just pull the rug out from under people. It's
> painful, but it's better to let people opt in to such a major change than
> to "break" their code.
>

We're talking about a deprecation, not removal of a feature.

First of all, it doesn't remove the feature, which means that everything
keeps working as-is, and second, we already have a way to configure error
reporting for deprecations ("configuration") ;-)

The point of deprecations is precisely to give downstream time to adjust
and release the adapted code, which we do all the time anyway.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/
On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev <[email protected]>
wrote:

> Hi!
>
> > To get the same benefits (jit and such) wouldn't it be better to
> introduce
> > a "use function root;" or similar statement or a declare() to specify
> this
> > file imports all root functions?
>
> We already have this right now, and realistically speaking, who wouldn't
> do that in their code instead of writing weird \strlen() code? Everybody
> would configure their IDEs and so to insert this automatically. So we're
> talking about RFC to make people work harder for what they already have
> now and then end up in the same place we are already right now.
>

Yes we do have root namespace lookup, but its not automatic, it is only as
a fallback. This RFC is about removing the intermediate namespace'd check,
hence requiring \strlen.

My idea was to force all function lookups into the global nameespace first
by doing the declare or use. This way someone writing a file could state "i
dont use namespaced functions in this file, don't try to load them".

I agree its annoying and more work, just wanted to present it as an
alternative option.


>
> > was acted on at any time in the future. and in addition people will
> silence
> > the notices on global error reporting level, because violations would
>
> And note also that we can't silence just this warning. Which means
> people would have to silence *all* warnings, thus making all other
> messages useless. This is not a good development and this is not what we
> should be training users to do - saying "well, it's a warning, just
> silence it" is the worth idea we could have. If we create a warning,
> recommendation should be "it's important enough so we call your
> attention to it, please deal with it", not "just silence it". If it's OK
> in most cases (as opposed to rare exceptional cases) for it to be
> silenced, it shouldn't be there in the first place.
>

Yes, this is why I have a problem with using E_STRICT (we don't have a lot
of them at the moment, but maybe in preparation of 8 more?) warning for it.
It would send a wrong signal to ignore rather than fix, because the amount
of violations would be massive.




>
> --
> Stas Malyshev
> smalyshev@gmail.com
>
On Mon, Feb 5, 2018 at 9:54 AM, Benjamin Eberlei <[email protected]> wrote:
> On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev <[email protected]>
> wrote:
>
>> Hi!
>>
>> > To get the same benefits (jit and such) wouldn't it be better to
>> introduce
>> > a "use function root;" or similar statement or a declare() to specify
>> this
>> > file imports all root functions?
>>
>> We already have this right now, and realistically speaking, who wouldn't
>> do that in their code instead of writing weird \strlen() code? Everybody
>> would configure their IDEs and so to insert this automatically. So we're
>> talking about RFC to make people work harder for what they already have
>> now and then end up in the same place we are already right now.
>>
>
> Yes we do have root namespace lookup, but its not automatic, it is only as
> a fallback. This RFC is about removing the intermediate namespace'd check,
> hence requiring \strlen.
>
> My idea was to force all function lookups into the global nameespace first
> by doing the declare or use. This way someone writing a file could state "i
> dont use namespaced functions in this file, don't try to load them".
>
> I agree its annoying and more work, just wanted to present it as an
> alternative option.
>
>
>>
>> > was acted on at any time in the future. and in addition people will
>> silence
>> > the notices on global error reporting level, because violations would
>>
>> And note also that we can't silence just this warning. Which means
>> people would have to silence *all* warnings, thus making all other
>> messages useless. This is not a good development and this is not what we
>> should be training users to do - saying "well, it's a warning, just
>> silence it" is the worth idea we could have. If we create a warning,
>> recommendation should be "it's important enough so we call your
>> attention to it, please deal with it", not "just silence it". If it's OK
>> in most cases (as opposed to rare exceptional cases) for it to be
>> silenced, it shouldn't be there in the first place.
>>
>
> Yes, this is why I have a problem with using E_STRICT (we don't have a lot
> of them at the moment, but maybe in preparation of 8 more?) warning for it.
> It would send a wrong signal to ignore rather than fix, because the amount
> of violations would be massive.

It's fine to ignore them as long as they fix them later. That's
precisely why I think E_STRICT is a good category for these notices.
If, however, they ignore them forever that's their fault; we are
simply providing advanced notice of a behavior we'd like to eventually
change.

Let me put "eventually" into perspective. We will probably have a 7.3
before we have an 8.0. This means that 8.0, the absolute earliest
version we could remove this feature, is at least 2 years away before
it reaches *any* of our users. Unless we extend it like we did with
the last 5.X release (and I think we probably should extend it) this
means that users can run their existing code on an officially
supported PHP 7 release for the next 4 years at the minimum. I am
fairly confident that for one reason or another it will delay another
year or two, putting it at 5-6 years.

If we are uncomfortable removing this feature in PHP 8.0 that means
support would extend until the end of the last PHP 8 release. My best
guess is that is at least 5 more years but probably more. That puts us
in the 10-12 years timeframe. If we cannot fix such an issue *over an
entire decade* then we may as well call PHP 7 the last major release.

And let me be clear: I would like there to be a PHP 8 and a PHP 9. I
think most of our users would like that as well. This means we have
breaking to do over the next decade. The responsible thing is to give
users this information as early as possible.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Sorry, only registered users may post in this forum.

Click here to login