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

2018-02-13 Thread S.A.N
If you implement scalar objects: https://github.com/nikic/scalar_objects Then 80% of global functions (array_*, str_*) will be localized using scalar object methods ($array->split(), $string->join()) and the PHP developer's response will be positive. Thanks. -- PHP Internals - PHP Runtime

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

2018-02-07 Thread Christoph M. Becker
On 06.02.2018 at 20:31, Stanislav Malyshev wrote: >> 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. > > We are talking about global namespace aka standard PHP functions, so it > works

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

2018-02-07 Thread Rowan Collins
On 7 February 2018 at 16:56, Andrey Andreev wrote: > Hi, > > What's not obvious (to me at least) here is why is the current > behavior preventing a ("sensible", as the RFC desribes it) > implementation of function autoloading? That seems to be a major > motivation factor for

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

2018-02-07 Thread Andrey Andreev
Hi, What's not obvious (to me at least) here is why is the current behavior preventing a ("sensible", as the RFC desribes it) implementation of function autoloading? That seems to be a major motivation factor for the proposal, yet doesn't seem to be explained anywhere. Cheers, Andrey. -- PHP

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

2018-02-07 Thread Rowan Collins
On 7 February 2018 at 15:20, Christoph M. Becker wrote: > On 07.02.2018 at 15:02, Rowan Collins wrote: > > > - PHP 7.3: Add syntax to explicitly reference functions and constants in > > the current namespace, such as .\foo or this\foo > > It is already possible to use the

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

2018-02-07 Thread Levi Morrison
On Wed, Feb 7, 2018 at 7:02 AM, Rowan Collins wrote: > On 3 February 2018 08:27:18 GMT+00:00, Wes wrote: >>Hello PHPeople. I just published the RFC "Deprecation of fallback to >>root >>scope". >>

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

2018-02-07 Thread Christoph M. Becker
On 07.02.2018 at 15:02, Rowan Collins wrote: > - PHP 7.3: Add syntax to explicitly reference functions and constants in > the current namespace, such as .\foo or this\foo It is already possible to use the `namespace` keyword for this, see . > - Slightly uglier syntax.

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

2018-02-07 Thread Rowan Collins
On 3 February 2018 08:27:18 GMT+00:00, Wes wrote: >Hello PHPeople. I just published the RFC "Deprecation of fallback to >root >scope". > >https://wiki.php.net/rfc/fallback-to-root-scope-deprecation Given the discussion so far, how about taking the "opposite" approach:

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

2018-02-06 Thread Stanislav Malyshev
Hi! > It's an ironic coincidence that you use strlen() as an example. > Because it and substr() are possibly the most likely to be overriden, > where we need code to be byte-safe in spite of mbstring.func_overload. Also happens rather rarely, in my impression, since you'd have to a) run

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

2018-02-06 Thread Andrey Andreev
Hi, > Realistically, how often do you override strlen? If I say "never", I > probably would be close enough for all practical purposes. It's an ironic coincidence that you use strlen() as an example. Because it and substr() are possibly the most likely to be overriden, where we need code to be

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

2018-02-06 Thread Stanislav Malyshev
Hi! > We're talking about a deprecation, not removal of a feature. There's no point of deprecating if the goal isn't to remove. > 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

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

2018-02-06 Thread Stanislav Malyshev
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, […] > > Do we? AFAIK, it is not possible to import *all*

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

2018-02-06 Thread Stanislav Malyshev
Hi! >> 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? No. Function autoloading addresses the needs of tiny part of the

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

2018-02-06 Thread Stanislav Malyshev
Hi! > I also think it's a stretch to call people affected by this change "our > worst users". I don't know if any common coding standards cover leading I think you can call them just "our users". I haven't seen any code that does \strlen or \substr all over the code base. In my opinion,

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

2018-02-06 Thread Stanislav Malyshev
Hi! > That said, I'm not sure that function autoloading will be that big of a > carrot > for the major projects at this point. Wordpress is going to ignore anything If they pay for that is to edit every single file that uses global functions (which is all of them) or suffer a hailstorm of

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

2018-02-06 Thread Stanislav Malyshev
Hi! > 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. It is automatic, in the meaning you don't have to do anything to get it. Realistically, how often do you

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

2018-02-06 Thread Rowan Collins
On 6 February 2018 at 14:36, Levi Morrison wrote: > > That's why I think having some concrete benefit much sooner is the only > way > > to stop people resenting this change. Build function autoloading in a way > > that it only works if you opt out of the fallback, and *then*

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

2018-02-06 Thread Ryan Pallas
On Tue, Feb 6, 2018 at 8:24 AM, Larry Garfield wrote: > > > That said, I'm not sure that function autoloading will be that big of a > carrot > for the major projects at this point. Wordpress is going to ignore > anything > we do here anyway for at least 15 years, and

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

2018-02-06 Thread Larry Garfield
On Tuesday, February 6, 2018 4:08:03 AM CST Rowan Collins wrote: > On 6 February 2018 at 01:51, Levi Morrison wrote: > > 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

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

2018-02-06 Thread Levi Morrison
On Tue, Feb 6, 2018 at 3:08 AM, Rowan Collins wrote: > On 6 February 2018 at 01:51, Levi Morrison wrote: > >> 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,

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

2018-02-06 Thread Rowan Collins
On 6 February 2018 at 01:51, Levi Morrison wrote: > 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

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

2018-02-05 Thread Levi Morrison
On Mon, Feb 5, 2018 at 9:54 AM, Benjamin Eberlei wrote: > On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev > wrote: > >> Hi! >> >> > To get the same benefits (jit and such) wouldn't it be better to >> introduce >> > a "use function root;" or similar

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

2018-02-05 Thread Benjamin Eberlei
On Sun, Feb 4, 2018 at 10:56 PM, Stanislav Malyshev 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

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

2018-02-05 Thread Marco Pivetta
On Mon, Feb 5, 2018 at 3:39 PM, Michael Morris wrote: > > > On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta wrote: > >> >> On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris >> wrote: >> >>> The problem is that behavior has been around so

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

2018-02-05 Thread Michael Morris
On Mon, Feb 5, 2018 at 8:33 AM, Marco Pivetta wrote: > > On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris 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

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

2018-02-05 Thread Marco Pivetta
On Mon, Feb 5, 2018 at 3:28 PM, Michael Morris 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

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

2018-02-05 Thread Michael Morris
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

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

2018-02-05 Thread Christoph M. Becker
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?

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

2018-02-05 Thread Rowan Collins
On 5 February 2018 at 12:54, Marco Pivetta wrote: > On Mon, Feb 5, 2018 at 1:52 PM, Rowan Collins > wrote: > >> None of these options is particularly appealing, and this will all be for >> a >> hypothetical future improvement to the language. >> > >

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

2018-02-05 Thread Marco Pivetta
On Mon, Feb 5, 2018 at 1:52 PM, Rowan Collins 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?

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

2018-02-05 Thread Rowan Collins
On 5 February 2018 at 10:53, Marco Pivetta 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

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

2018-02-05 Thread Marco Pivetta
Hey Ivan, On 5 Feb 2018 11:18, "Ivan Enderlin" 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,

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

2018-02-05 Thread Ivan Enderlin
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

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

2018-02-04 Thread Levi Morrison
On Sun, Feb 4, 2018 at 2:56 PM, Stanislav Malyshev 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

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

2018-02-04 Thread Stanislav Malyshev
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

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

2018-02-04 Thread Benjamin Eberlei
On Sat, Feb 3, 2018 at 9:27 AM, 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

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

2018-02-04 Thread Rowan Collins
On 3 February 2018 08:27:18 GMT+00:00, 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

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

2018-02-04 Thread Stanislav Malyshev
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

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

2018-02-04 Thread Wes
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

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

2018-02-03 Thread Aaron Piotrowski
> On Feb 3, 2018, at 11:04 AM, Sara Golemon 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

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

2018-02-03 Thread Sara Golemon
On Sat, Feb 3, 2018 at 11:31 AM, Levi Morrison 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

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

2018-02-03 Thread Marcio Almada
2018-02-03 14:46 GMT-02:00 Marcio Almada : > > 2018-02-03 6:27 GMT-02:00 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 >>

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

2018-02-03 Thread Marcio Almada
2018-02-03 6:27 GMT-02:00 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

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

2018-02-03 Thread Levi Morrison
On Sat, Feb 3, 2018 at 3:22 AM, Wes 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

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

2018-02-03 Thread Marco Pivetta
On Sat, Feb 3, 2018 at 1:15 PM, Wes 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

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

2018-02-03 Thread Wes
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

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

2018-02-03 Thread Wes
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

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

2018-02-03 Thread Niklas Keller
+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

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

2018-02-03 Thread Wes
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 =

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

2018-02-03 Thread Marco Pivetta
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 wrote: >

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

2018-02-03 Thread 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