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
mbstring.
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 by
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 why is it any
>more
>> "hidden" than any other
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 2018 20:18:07 GMT+00:00, M
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 dependency". It's a dependency,
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 >
> >>
> >> wrote:
> >> > Really, these functions would be
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 d
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* fu
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 us
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, requiring
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 war
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 overrid
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) mi
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* deprecate
> the
> > f
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 pretty much every other
> pro
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 ignore them foreve
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, however, they ignore them forever that's the
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 notice of a beh
18 matches
Mail list logo
