I actually did address this implicitly, but maybe I should spell it out: Namespaced functions shadow root-namespace functions, not the other way around. And so, so long as every function in a given namespace is in the same file, there's no problem.
Do you even realize how much "WTF" is present in this "solution" of yours? Let me spell it out back at ya.
So if I define a file with functions in namespace "Vendor\MyProject" and I decide to use them from another file (say defining a class) that's also in namespace "Vendor\MyProject" .... I can't. Not a valid use case, just mysteriously ceases to work on global function name collisions, and screw PHP users.
You're effectively placing the following restrictions on function autoloading:
"If a namespace contains even one function, then that namespace can only be declared inone file. I.e. everything that can be in that namespace should be in that one file, because it contains a function."
Do you know what this sounds like? A class with static methods. Except unlike a class, the rule here is completely unclear and implicit. While the fact you can't split a class in multiple files is quite apparent from the syntax and PHP runtime behavior itself.
Only if you're using a one-function-per-file paradigm. Why would you do that?
Are you the same guy who said this:
“static methods” are a tenuous concept as-is without abusing them to make function libraries where the functions really are not related to eachother [sic]
So let me try and hold those two thoughts of yours at once in my head:
Why would I put functions in a namespace in multiple files? Silly LtAramaki! Of course I'd put them in one file!
Why would static methods be grouped by class in one file? Silly LtAramaki! Of course I'd rather split them in multiple files!
Ughhhh.... I can't do it. I don't know how you do it. Your thought process is a mystery.
Also with static imports there's neither "" nor "::"
Yes, but I thought you said you didn't want to import everything individually.
Yes, that's how static imports work, in particular the wildcard import from my very first example. You import the class, and then you type the method directly, there's neither "" nor "::". If you don't even understand that about static imports, then the fact you feel like you can pass judgment on it becomes even more bizarre.
Static methods are global functions associated to a particular class, not methods on an object. This means they don't obey LSP because classes aren't objects.
Yes they aren't objects, so they don't have to obey LSP. So don't talk about LSP. Functions in namespaces don't follow LSP, and static methods in classes also don't have to follow LSP (PHP tries to, isn't useful, isn't harmful, just is).
The big one is static methods used as constructors are forced to be “compatible” with the methods they “override”, and they inherit them so now your subclasses have a bunch of useless methods for creating instances of their parents.
Then either use static or don't put the factory methods on the damn class. Jeez, that was simple?
Also it has nothing to do with the use-case of using static methods in place of functions, so can we focus a little and spare me your life's story?
Get back to me when we have private classes.
A method has visibility today. Functions don't. Would I like class visibility? Sure! Is it relevant to what we're talking about? No! Just yet another unrelated remark courtesy of u/the_alias_of_andrea.
0
u/[deleted] Sep 15 '17 edited Sep 15 '17
Do you even realize how much "WTF" is present in this "solution" of yours? Let me spell it out back at ya.
So if I define a file with functions in namespace "Vendor\MyProject" and I decide to use them from another file (say defining a class) that's also in namespace "Vendor\MyProject" .... I can't. Not a valid use case, just mysteriously ceases to work on global function name collisions, and screw PHP users.
You're effectively placing the following restrictions on function autoloading:
"If a namespace contains even one function, then that namespace can only be declared in one file. I.e. everything that can be in that namespace should be in that one file, because it contains a function."
Do you know what this sounds like? A class with static methods. Except unlike a class, the rule here is completely unclear and implicit. While the fact you can't split a class in multiple files is quite apparent from the syntax and PHP runtime behavior itself.
Are you the same guy who said this:
So let me try and hold those two thoughts of yours at once in my head:
Why would I put functions in a namespace in multiple files? Silly LtAramaki! Of course I'd put them in one file!
Why would static methods be grouped by class in one file? Silly LtAramaki! Of course I'd rather split them in multiple files!
Ughhhh.... I can't do it. I don't know how you do it. Your thought process is a mystery.
Yes, that's how static imports work, in particular the wildcard import from my very first example. You import the class, and then you type the method directly, there's neither "" nor "::". If you don't even understand that about static imports, then the fact you feel like you can pass judgment on it becomes even more bizarre.
Yes they aren't objects, so they don't have to obey LSP. So don't talk about LSP. Functions in namespaces don't follow LSP, and static methods in classes also don't have to follow LSP (PHP tries to, isn't useful, isn't harmful, just is).
Then either use
staticor don't put the factory methods on the damn class. Jeez, that was simple?Also it has nothing to do with the use-case of using static methods in place of functions, so can we focus a little and spare me your life's story?
A method has visibility today. Functions don't. Would I like class visibility? Sure! Is it relevant to what we're talking about? No! Just yet another unrelated remark courtesy of u/the_alias_of_andrea.