Welcome! Log In Create A New Profile

Advanced

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

Posted by Wes 
On 6 February 2018 at 01:51, Levi Morrison <[email protected]> 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 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.
>


I think for a lot of people the "forever" in your first paragraph and the
"5-6 years" in your second paragraph will feel like the same thing. If the
message is "this might be removed some time in the next decade", people
will simply shrug and ignore it until an actual removal is announced;
thinking as a cynical user, there's no guarantee the recommendation won't
be changed back in future - we've had features "undeprecated" before.

As others have pointed out, even if you run an analyser over your own code
base to add \ in the appropriate places, you can't turn on E_STRICT notices
without being flooded until all your dependencies have done the same - and
there's no compelling reason for them to do so.

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
fallback mode, and it feels like progress rather than disruptive tinkering.

Regards,
--
Rowan Collins
[IMSoP]
On Tue, Feb 6, 2018 at 3:08 AM, Rowan Collins <[email protected]> wrote:
> On 6 February 2018 at 01:51, Levi Morrison <[email protected]> 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 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.
>>
>
>
> I think for a lot of people the "forever" in your first paragraph and the
> "5-6 years" in your second paragraph will feel like the same thing. If the
> message is "this might be removed some time in the next decade", people
> will simply shrug and ignore it until an actual removal is announced;
> thinking as a cynical user, there's no guarantee the recommendation won't
> be changed back in future - we've had features "undeprecated" before.
>
> As others have pointed out, even if you run an analyser over your own code
> base to add \ in the appropriate places, you can't turn on E_STRICT notices
> without being flooded until all your dependencies have done the same - and
> there's no compelling reason for them to do so.
>
> 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
> fallback mode, and it feels like progress rather than disruptive tinkering.

This thinking is too pessimistic. We cannot design to appease our
worst users. The advanced notice is better than a sudden one even if
we have function autoloading.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tuesday, February 6, 2018 4:08:03 AM CST Rowan Collins wrote:
> On 6 February 2018 at 01:51, Levi Morrison <[email protected]> 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 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.
>
> I think for a lot of people the "forever" in your first paragraph and the
> "5-6 years" in your second paragraph will feel like the same thing. If the
> message is "this might be removed some time in the next decade", people
> will simply shrug and ignore it until an actual removal is announced;
> thinking as a cynical user, there's no guarantee the recommendation won't
> be changed back in future - we've had features "undeprecated" before.
>
> As others have pointed out, even if you run an analyser over your own code
> base to add \ in the appropriate places, you can't turn on E_STRICT notices
> without being flooded until all your dependencies have done the same - and
> there's no compelling reason for them to do so.
>
> 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
> fallback mode, and it feels like progress rather than disruptive tinkering.
>
> Regards,

Potential benefits of this change aside, I have to agree with Rowan on tactics.
A carrot works much better than a stick in this case. Remember also that many
larger systems stay around and in production WAAAAAAAAAAAAY past their
expected lifetimes; there are still poor souls running PHP 4, and I personally
know of Drupal 5 sites still in the wild. So even if the HEAD version of
everything is updated within a year for such a change the long tail of what's
running out in the world will lag badly.

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 project
in existence has gone all-OOP or nearly-all-OOP at this point (good or bad is
beside the point). Namespaced user defined functions are rare in my experience
outside of very specific libraries (such as functional tooling libs). So "yay,
you can now autoload namespaced user-defined functions" will likely be met with
a lot of "what are those?"

--Larry Garfield
On Tue, Feb 6, 2018 at 8:24 AM, Larry Garfield <[email protected]>
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
> project
> in existence has gone all-OOP or nearly-all-OOP at this point (good or bad
> is
> beside the point). Namespaced user defined functions are rare in my
> experience
> outside of very specific libraries (such as functional tooling libs). So
> "yay,
> you can now autoload namespaced user-defined functions" will likely be met
> with
> a lot of "what are those?"
>
>
I disagree with this assessment. Many functions are actually collected in
static classes so they can be autoloaded. So instead of,

namespace Foo\Bar;

class Map {
public static function modelToApi(Model $model) : array {}
}

The function can now just be in a namespace directly, instead of treating a
class like a namespace. You can then also import just the function you
need, instead of the whole class. Many of these classes exist in projects
I've worked on just for the purpose of being able to autoload the functions
when needed. My 2 cents.


> --Larry Garfield
On 6 February 2018 at 14:36, Levi Morrison <[email protected]> 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
> > fallback mode, and it feels like progress rather than disruptive
> tinkering.
>
> This thinking is too pessimistic. We cannot design to appease our
> worst users. The advanced notice is better than a sudden one even if
> we have function autoloading.
>


Perhaps I wasn't clear; I'm not saying the transition should be more
sudden, I'm just saying that we should introduce an opt-in advantage
alongside the flood of messages.

As I understand it, the timeline you support is:
* Raise E_STRICT in PHP 7.3.
* Once we have a plan to actually change the behaviour, move to
E_DEPRECATED, e.g. in PHP 7.5, or 8.0.
* Remove fallback at the same time as introducing autoloading, in PHP 8.0
or maybe 9.0.

The timeline I am suggesting is:
* Add an opt-in feature which enables some advantage, probably autoloading,
as soon as possible, e.g. PHP 7.3 or 7.4
* Raise E_DEPRECATED for code which doesn't opt in and doesn't
fully-qualify function names, once usage is established, e.g. PHP 7.5, or
8.0
* Remove the fallback mode as a purely internal change, in PHP 8.0 or 9.0.

People would still be changing code on much the same timeline, but we
wouldn't have the long period of telling people to change all their code
without any benefit to them or us.

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
backslashes (I searched the PSR-12 draft and Drupal style guide and neither
seems to mention it) but if they do, they're as likely to say "never add
them" as "always add them", particularly given their use as a hack to
"mock" global functions. Or perhaps by "worst users" you mean "users not
willing to change their code" - in which case remember that this is a
disruptive and risky change to an entire code base for no immediate
benefit; putting off such a change might be a perfectly rational decision.

Regards,
--
Rowan Collins
[IMSoP]
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:20PM
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 override strlen? If I say "never", I
probably would be close enough for all practical purposes.

> 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".

Why? We already have this working, why make it harder by requiring to do
specific things that we know upfront 99%+ people end up doing? Why not
assume them by default?

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:30PM
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 warnings then
I don't think any carrot would be large enough for this. And, frankly,
the amount of cases where I absolutely needed namespace function
autoloading and couldn't do without it (like, using classes) I probably
could count on the fingers of one hand, and I still could type while
doing it.

I mean, I don't necessarily have anything against adding this feature,
but if the progression goes from "we need namespaced functions" to "we
need namespaced autoloaded functions" to "we can't use strlen without
ridiculous prefixing or adding "yes, I still want strlen" in every file
every time" then I'd rather not have namespaced functions at all than
deal with that.

> outside of very specific libraries (such as functional tooling libs). So "yay,
> you can now autoload namespaced user-defined functions" will likely be met with
> a lot of "what are those?"

It won't be just "yay, you can now autoload namespaced user-defined
functions", it would be "yay, all code that uses strlen is not throwing
noisy warnings, but on the other hand, we made this obscure feature you
never used easier, so rejoice!" I wouldn't rejoice.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:30PM
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
this would be a huge annoyance to our users and make no sense at all.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:30PM
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 users.
While I am far from discounting these needs - they are still valid needs
and we may want to serve them if we can - if the costs is to impose a
huge burden on the rest of the users it doesn't make it much better.
It's the situation of "we just broke all your code" vs. "we just broke
all your code, but some of *our* code is now easier to write". Not much
of an improvement, I think.

--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:40PM
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* 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 out of the box. If you're talking about non-global namespace,
there's no such thing as "all functions of a namespace" at all, and even
if there were, in most cases it's the wrong thing (excepting some rare
cases like you want to override all PHP function for testing, etc.) to
do. Namespaces are meant to keep things separate, so blanket imports
just put us back into a pre-namespace world with all the problems that
existed there.
Granted, there are rare cases - as overriding whole extension or whole
standard library - but they are rare. In overwhelming majority of cases,
this is not what should be done and if you do it, you usually get in
trouble.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 06, 2018 08:40PM
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 deprecations ("configuration") ;-)

Configuration removes deprecation messages as a whole class, which is
usually not what you want.

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

In this case, this would mean "edit every file (that uses standard PHP
functions, which is probably nearly every file in the codebase)", to no
benefit to the user. This is a huge imposition on existing users without
any benefit to them. The fact that they will have time is irrelevant -
they always would have all the time in the world but not upgrading - the
point is that this change is bad for them.
--
Stas Malyshev
smalyshev@gmail.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 byte-safe in spite of mbstring.func_overload.

But why does that matter, either way?

Cheers,
Andrey.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Stanislav Malyshev
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 07, 2018 05:00AM
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.func_overload which you can't remove and b) still need
non-overloaded string functions. And if you are in this rare situation,
it's usually better to have explicitly-named function, so that you know
what you are dealing with, not relying on subtle details of how names
are resolved vs. namespaces.
--
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".
>
>https://wiki.php.net/rfc/fallback-to-root-scope-deprecation


Given the discussion so far, how about taking the "opposite" approach:
deprecate unprefixed reference to functions which *are* in the current
namespace.

Proposal:
- PHP 7.3: Add syntax to explicitly reference functions and constants in
the current namespace, such as .\foo or this\foo
- PHP 7.4: Raise E_DEPRECATED whenever an unprefixed function/constant
resolves to something in the current namespace (other than via "use" alias)
- PHP 8.0: Make all unprefixed functions/constants always refer to the root
namespace

Pros:
- Much less disruptive change, as the majority of unprefixed function calls
are to global functions, and would not need to change.
- Both cases can be made unambiguous if the author wants to.
- Apparently OpCache currently mitigates the performance hit by caching
lookups in a technically unclean way. Users hit by this can make their code
unambiguous in 7.3, and the optimisation will become clean in 8.0.
- Function / constant autoloading can be added in 7.x if we accept the
caveat that unprefixed functions will not be autoloaded; or in 8.0 if we
want to cover everything.

Cons:
- Slightly uglier syntax.
- Still a breaking change (in 8.0).
- Class names will still be resolved differently from function and constant
names.
- Code actively using the fallback system (e.g. tests masking global
functions with mocks) will need refactoring as there is no way to opt into
the old behaviour.
- The .\foo() syntax may appear in similar places to the . concatenation
operator. Even if technically unambiguous and implementable in the parser,
this may be confusing to users. A keyword approach like this\foo() would be
clearer, but more verbose.

What do people think? Is it worth expanding this out into an alternative
RFC?

Regards,
--
Rowan Collins [IMSoP]
Christoph M. Becker
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 07, 2018 04:30PM
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
https://3v4l.org/bikjE.

> - Slightly uglier syntax.

IMHO, .\foo is very ugly, and namespace\foo is not much better.

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Wed, Feb 7, 2018 at 7:02 AM, Rowan Collins <[email protected]> wrote:
> 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".
>>
>>https://wiki.php.net/rfc/fallback-to-root-scope-deprecation
>
>
> Given the discussion so far, how about taking the "opposite" approach:
> deprecate unprefixed reference to functions which *are* in the current
> namespace.
>
> Proposal:
> - PHP 7.3: Add syntax to explicitly reference functions and constants in
> the current namespace, such as .\foo or this\foo
> - PHP 7.4: Raise E_DEPRECATED whenever an unprefixed function/constant
> resolves to something in the current namespace (other than via "use" alias)
> - PHP 8.0: Make all unprefixed functions/constants always refer to the root
> namespace
>
> Pros:
> - Much less disruptive change, as the majority of unprefixed function calls
> are to global functions, and would not need to change.
> - Both cases can be made unambiguous if the author wants to.
> - Apparently OpCache currently mitigates the performance hit by caching
> lookups in a technically unclean way. Users hit by this can make their code
> unambiguous in 7.3, and the optimisation will become clean in 8.0.
> - Function / constant autoloading can be added in 7.x if we accept the
> caveat that unprefixed functions will not be autoloaded; or in 8.0 if we
> want to cover everything.
>
> Cons:
> - Slightly uglier syntax.
> - Still a breaking change (in 8.0).
> - Class names will still be resolved differently from function and constant
> names.
> - Code actively using the fallback system (e.g. tests masking global
> functions with mocks) will need refactoring as there is no way to opt into
> the old behaviour.
> - The .\foo() syntax may appear in similar places to the . concatenation
> operator. Even if technically unambiguous and implementable in the parser,
> this may be confusing to users. A keyword approach like this\foo() would be
> clearer, but more verbose.
>
> What do people think? Is it worth expanding this out into an alternative
> RFC?
>
> Regards,
> --
> Rowan Collins [IMSoP]

My opinion is that the result is both uglier and *even less
consistent* with namespaced types. I'm glad you are at least thinking
about alternative proposals but this is worse than both the original
proposal and doing nothing.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 7 February 2018 at 15:20, Christoph M. Becker <[email protected]> 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 `namespace` keyword for this, see
> https://3v4l.org/bikjE.
>


Huh, I never knew that! Funnily enough, I thought of that as a possibility
(because it's already a reserved word) but rejected it as too long. :P



> > - Slightly uglier syntax.
>
> IMHO, .\foo is very ugly, and namespace\foo is not much better.
>


Yeah; the question is whether that ugliness is something we're willing to
live with for the performance and features it would enable. Most code would
still be less ugly than if we had to prefix all global functions, anyway.

Something worth considering is that even when using namespaced functions,
the shorthand is only available in *exactly the current namespace*, so
you're rather likely to be qualifying or importing them anyway. For
instance, they might be in a child or neighbouring namespace called
"...\functions" or " ...\ utils" or " ...\ streams".

Regards,
--
Rowan Collins
[IMSoP]
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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 7 February 2018 at 16:56, Andrey Andreev <[email protected]> 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 the proposal, yet doesn't seem to be explained
> anywhere.
>


It's not been mentioned explicitly in this thread, but has come up a lot in
previous discussions. I'll attempt to summarise my understanding.

Currently, when you write "foo()" in code marked as namespace "Bob", the
engine does this:

1. Check for a function "Bob\foo", use it if defined
2. Check for a function "foo", use it if defined
3. Raise an error if neither is defined

If we add autoloading of functions, the logical sequence would be to
attempt the autoloader every time we encounter something not defined:

1. Check for a function "Bob\foo", use it if defined
1a. Run autoloader callback for "Bob\foo"; use function if one is now
defined
2. Check for a function "foo", use it if defined
2a. Run autoloader callback for "foo"; use function if one is now defined
3. Raise an error if neither is defined

The problem is that all of this has to happen *every time you call the
function*, because at any time, the function could be registered, or a new
autoloader registered that knows where to find it.

If "foo" is actually a global function, that means steps 1 and 1a will be
run every time your use of "foo()" is reached, meaning that every call has
an additional overhead of calling the autoloader callback.

Since the autoloader callback might in fact be a whole stack of registered
closures, this means a significant overhead every time you mention any
global function, which includes 90% of PHP's standard library.

I hope that clarifies the general problem (and that I haven't made any
mistakes in my explanation).

Regards,
--
Rowan Collins
[IMSoP]
Christoph M. Becker
Re: [PHP-DEV] [RFC][DISCUSSION] Deprecation of fallback to root scope
February 07, 2018 06:50PM
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 out of the box. […]

Ah, I see. :)

--
Christoph M. Becker

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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 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