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

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

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] Collection Inspection

On 6 February 2018 21:10:54 GMT+00:00, Michael Morris wrote: >On Tue, Feb 6, 2018 at 2:54 PM, Rowan Collins >wrote: >> I may be being dumb, but I don't get why you keep referring to this >as a >> "hidden dependency". It's a dependency, for sure, but

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

The Dependency injector isn't aware of the reference and is unable to modify it in any way. I've been taught to avoid such dependencies, and to avoid utility libraries which create such dependencies. On Tue, Feb 6, 2018 at 2:54 PM, Rowan Collins wrote: > On 6 February

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On 6 February 2018 20:18:07 GMT+00:00, Michael Morris wrote: >I'm fine with this - I just want the inspector to be part of the >language >so that a hidden dependency isn't required. I may be being dumb, but I don't get why you keep referring to this as a "hidden

Re: [PHP-DEV][RFC][DISCUSSION] Collection Inspection

On Tue, Jan 30, 2018 at 2:24 PM, Levi Morrison wrote: > On Tue, Jan 30, 2018 at 11:13 AM, Larry Garfield > wrote: > > On Monday, January 29, 2018 6:46:10 PM CST Michael Morris wrote: > >> On Mon, Jan 29, 2018 at 6:16 PM, Larry Garfield

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

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

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

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

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

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

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

[PHP-DEV] Re: What to do with bundled GD's version info?

Hi Andrea! On 05.02.2018 at 03:35, Andrea Faulds wrote: > Christoph M. Becker wrote: > >> So the question is how to handle the version information of the bundled >> libgd for the time being.   With regard to gd_info()['GD Version'] just >> saying "bundled" (without any compatibility statement)

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

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

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

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

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

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