Source
MeLoN_DO•

I understand the problem it's trying to solve, but the issue is that there are so many native global functions.

How about trying to kill two birds with one stone? The standard library has been in need on a major cleanup forever. We could move them to their own namespace, keeping an alias in the root namespace for the time being. Also taking this opportunity to fix the arguments order inconsistencies.

That way, when devs go through their code to modernize it, making sure the calls are namespaced, they can migrate to use the new standard functions.

Ex:

use std\array;
use std\string;

array\pos(needle, haystack);
string\pos(needle, haystack);
23
MorrisonLevi•

Are "array" and "string" valid namespace names? "string" I can see but array is a keyword and I am doubtful.

2
MeLoN_DO•

Arrays or str, whatever.

Also, if it's for the standard lib, I'm sure something can be figured out

2
MorrisonLevi•

I'm not sure you, or anyone else, who suggests these types of endeavors really understands how much work it is. I don't mean it as an insult; it's just that design is difficult and slow work. For instance you used "pos". Is that really a good name? Additionally what if we get named arguments; wouldn't it be better to have a new standard library designed around that where appropriate?

The sentiment is good but I doubt we will ever see such an effort truly realized.

2
captain_covfefe•

Riiight...

The whole language is one big bolted-on hack, syntactically speaking, but suddenly we can't solve some of its biggest problems because "what if we get named arguments someday?"

PHP has a major design paralysis problem. Ignoring today's concerns for fear of theoretical future hurdles is the quickest path to irrelevancy.

0
captain_covfefe•

\I'll happily \change my code to \just \about any \extent to \keep up with \modern \PHP, \but \this is just \silly. \The technical \motivations are \sound, but the \end \result looks like \dogshit.

22
perkia•

use {your, head};

11
captain_covfefe•

I'll just use { a, sane, version, of, PHP, that, won't, make, me, completely, hate, my, life, as, a, developer };

10
ThePa1nter•

Good luck finding one

0
muglug•

We can't have a bunch of nice things (including std library functions with good names and sane argument ordering) until this is fixed.

6
zimzat•

Alias them all onto objects like ArrayObject and you're half way there.

1
destraht•

You forgot to use slashes in your reply.

1
thinsoldier•

That's like people who say PHP looks like shit because $variables start with $.

0†
raziel2p•

Sounds horrible, having to use a ton of built-in functions or litter your code with slashes.

17
tfidry•

You are already doing it for classes or namespaced functions, look pretty reasonable to have it for the rest as well instead of doing some guess work

3
web_•

I like this. However I see resistance coming from a subset of the framework communities, particularly those frameworks with tons of 'helper' functions.

14
TinyLebowski•

Couldn't they just autoload those functions?

1†
ImSuperObjective2•

Autoloading and importing names (global names in this case) are two distinct problems with distinct solutions. This RFC is about importing names, not about autoloading.

3
Jake_Jeremy•

Deprecation warnings don't matter, and the RFC states that they'll most likely be removed (if ever) in the same step that introduces function autoloading. I don't see the problem.

2
ImSuperObjective2•

Interesting that I see this proposal. Technically it's sound, but you'll see a lot of emotional resistance, because it means one has to always prefix their function calls (or import them on top).

I feel this proposal has a better chance if we start a wholesale clean-up of all APIs by introducing the new versions in a namespace for ex. \php\str_length() to replace \strlen(). Then when people have to import to use the new APIs, they won't fight so viciously to preserve the right to NOT import the legacy APIs before they use them.

11
ocramiusOPZF2 / Doctrine Team•

It's much easier to use function str_length; btw (to avoid cluttering the codebase with inline diffs)

2
ImSuperObjective2•

Easy... I don't know, that's relative I guess. If the IDE inserts it for you, and then folds it, it's easy. IDEs have spotty support for this. Some offer it as an option, some don't.

Those that work in VIM and similar editors won't appreciate their source files being half function imports.

3
Firehed•

Vim user here; disagreed. There’s already enough use statements for OOP stuff that a few extra lines certainly won’t bother me.

3
web_•

Those that work in VIM and similar editors won't appreciate their source files being half function imports.

They should be careful with that logic. I've seen people make that argument regarding docblocks, and it usually doesn't end well.

2
ImSuperObjective2•

Doc blocks have a purpose more substantial than "hey, I'm using that function maybe". And I don't understand the "be careful" warning. There will be great resistance to such a change in PHP. How it'll be explained will vary, but if this vote passes on first try, I'll eat my hat.

That said, it's interesting to see this RFC even exists. Maybe the tide is turning. Slowly. I've always thought the function fallback is a major mistake, right from the moment namespaces were introduced in PHP 5.3.

7
ocramiusOPZF2 / Doctrine Team•

most fixers already have rules for this (and they integrate with editors ;-) )

2
localheinz•

Anyone unaware, friendsofphp/php-cs-fixer has got a NativeFunctionInvocationFixer.

3
tfidry•

FYI phpStorm can already do it: Editor > General > Auto Import

1
ImSuperObjective2•

I'm aware.

1
fire_fire_se•

Wouldn't that be use function \str_length; ?

1
ocramiusOPZF2 / Doctrine Team•

use statements are always referring to root scope, so the leading \ is not needed. Same goes for symbols references in strings.

2
Sentient_Blade•

Anything that makes the engine stricter and therefore presenting less surface for unexpected quirks is a good thing in my books.

I wonder though, isn't the more "obvious" long term solution to this particular problem to depreciate namespace level functions entirely in favour of static class functions and treat every other function call as if it was FQ? I know it feels a bit java-ish but it would fit in well with existing autoloading.

7
prema_van_smuuf•

I'd rather see this as an optional declare() directive - as it is now with strict types. Breaks too much and I feel the gain is very little for this to be the default behaviour.

5
WhatAboutBergzoid•

I think this is a great idea, but my god, can you imagine it with WordPress or some other garbage procedural code that does everything with root scope function calls? Not going to be fun.

I don't know the technical details of why this is necessary, but could a compromise be that built-in PHP functions don't need the root namespace prefix, but user-defined functions do?

What about a wildcard syntax that imports every function defined in a namespace? e.g.

use function \App\Helpers\*;
4
ocramiusOPZF2 / Doctrine Team•

If you do everything in the root scope, then no imports are needed at all...

19
sarciszewski•

Precisely, because you're not in a namespace.

2
MorphineAdministered•

How many functions other than native ones do you use? What year is it?

4
ocramiusOPZF2 / Doctrine Team•

Very few, and mostly because function autoloading is not really possible until this is fixed.

4
MorphineAdministered•

Importing static class is basically the same as importing function namespace.

0
tfidry•

yes, so instead of having a function you require people to create a class with a static method. Cool.

1
MorphineAdministered•

I'm saying not to get over excited about importing/autoloading functions, because there's no difference between them and static classes - both are hardcoded dependencies. It might make sense for std lib rewrite, but I don't see it coming anytime soon.

1
TheVenetianMask•

I feel this is a larger change than a 7.2 to 7.3 version would imply, if it comes along function autoloading.

4
MorrisonLevi•

You misunderstand. This is simply emitting a warning which based on the mailing list discussion is likely to have a severity of E_STRICT. It is not proposing function autoloading but is demonstrating that if we have function autoloading at the time we remove the feature which is not now it can be leveraged to minimize backwards compatibility issues.

10
send_me_a_naked_pic•

This could be an interesting way to fix the messy standard library, by using a new namespace (for example, \PHP). No more inconsistent function names or different order of parameters.

0
Zomgnerfenigma•

Bye bye php.

-8