Why do they keep adding global functions like "intdiv"? For example in JS, it being another language with a similar compatibility burden, they are moving most of the global functions (like parseInt) to "namespaces" (like Number.parseInt) while keeping global references there. When I open the docs (for example, the array functions page[1]), I get frightened by the global functions which do not seem to share a naming convention on first glance.
disclaimer: I haven't written anything significant with PHP since too many years.
This is ongoing in the PHP community. For those who like purity there are tons and tons of wrapper classes that hide all that stuff away.
Modern IDEs autocomplete all the functions, I'm using PHPStorm and as soon as I type 'arr' it shows me a list of all the array functions with parameters listed.
Not perfect, but if I was worried about that kind of thing I'd use Python (which I love) or RoR (which I also love).
I never understood this standpoint. I hear this from the Go community sometimes too. Wouldn't having some sane organization of functions make it easier to "just get stuff done"? Just like in Go, wouldn't generics make it easier to get stuff done?
PHP Developers who I've met at conferences and user groups talk about what they're building. Rarely do they seem to care that much about the language. I think many would be happy in many languages, its about being able to build something quickly. If its not elegant, nobody cares.
There are a lot of frameworks (too many frankly) and tooling that enable quick building of custom sites.
When you put stuff in namespaces you need to remember in which namespace it is (and which library to refrence).
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Sure, names of PHP functions look arbitrary and inconsistent but when you know the name of the function you know everything you need (apart from how to use it which you can quickly and unambigously check like: http://php.net/file_get_contents )
> Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() any day.
It doesn't have to be one or the other.
In fact, array functions could just be under the same static class, like Array::TheFunction() . It would be acceptable and limit chances of namespace collision .
Sure there's a spectrum. But even with one level I'm still guessing whether it was String.toInteger or Integer.toString, or String.parseInt or Integer.parseInt or Number.parseInt or whatever ... and since I need to check I don't mind finding out it's a global function named str2int or even int() that takes whatever.
If you have to look it up anyway, what difference does it make if it's a global or namespaces? If you don't know, you don't know. As such, your point as stated doesn't counteract why polluting global namespaces is a bad thing. There are arguments that could be made (PHP VM specific), but "I didn't ever RTFM and/or retain it" doesn't fly to me personally.
> what difference does it make if it's a global or namespaces?
I feel that it's often easier to remember short unique name like str2int than long, deceivingly reasonable name like: System.Web.Script.Serialization.JavaScriptSerializer.Serialize
I agree though that array_uniq is same as Array::uniq
> why polluting global namespaces is a bad thing.
Why is that bad for language wide utility functions?
I though global is bad mostly in your own custom code or you application specific libraries because it's accessible from everywhere which hides the dependencies (no to mention global mutable state which makes "action at distance" prevalent).
You love continuing to bring up the Java like example, this discussion however is about PHP. PHP will never have namespacing nested like that in the base language, so no point beating that dead horse.
> why is that bad for language wide utility functions?
There's a handful of reasons, but one important one is backwards compatibility with existing codebases (naming collisions).
Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() (or was it Newtonsoft.Json.JsonConvert.SerializeObject()?) any day.
Doesn't help you that much though when Microsoft releases new version of its web stack, naming different things with same class names as before just putting them in different namespace. I still need to guess which of the namespaces I actually need when I'm trying to get running something that I found on the internet.
The basic functionality (given type X import namespace Y) is built into Visual Studio since who-knows-when [1].
In my opinion if you are doing a lot of commercial .NET development then ReSharper isn't an optional extra. Rather, it's money well spent. You get more complete functionality: ReSharper 8 added the smarts to look for NuGet packages in your solution and reference the correct NuGet package. (This is ALT+ENTER and it basically gets the right type and dependency first time around.)
ReSharper 9 goes further and allows you to find types in any package on NuGet - JetBrains maintains their own index of NuGet packages for this purpose [2].
All the existing math functions are global. If you add a new one, it's only fitting that it is global too. Having one and only one math function namespaced would be inconsistent.
Not to mention, if they namespaced all math functions it'd break backward compatibility badly. Given that no core PHP functions are namespaced, I don't see why they should start now.
Also, with the functions in the global namespace you can implement a namespaced copy that takes precedence within the namespace and its children. It can easily confuse people, but I've seen it used to force people away from string functions to their multibyte equivalents (it threw exceptions).
disclaimer: I haven't written anything significant with PHP since too many years.
[1]: http://php.net/manual/en/ref.array.php