4 ms·
> Number.parseInt is not that bad but I'll take to_json() global function instead of (new System.Web.Script.Serialization.JavaScriptSerializer()).Serialize() an
by aikah 11y ago
> 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 .
- scotty79 11y ago> It doesn't have to be one or the other. 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.
- jsjohnst 11y agoIf 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.
- scotty79 11y ago> 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).
- jsjohnst 11y agoYou 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).
- deleted 11y ago[deleted]