>The point is that I do not see this feature at all relevant to >solving the web problem. This is where PHP needs to focus. Namespaces >help in solving the web problem, because it eases cooperation of >independent developers to supply libraries. The feature you are >proposing is solved easily in userland (just like named parameters). >Its is a feature I could see using in a heavy lifting language, but >not in a glue language. Where do we draw the line? Somewhere >relatively arbitrary, but my gut tells me that this is a good >candidate to be on "lets leave it out of php" side of the line. > >regards, >Lukas
When it comes to interoperation between systems and or developers, it is always a good idea to define strict standards of how the communication between libarys and components has to take place (since public methods are something like an interface bewteen interoperating libraries and classes), to be sure that all components work together as expected. One of the best approaches to explain the usage of the class to a foreign developer and to be sure that your class is used correctly and help the foreign developer to understand how your classes have to be used (beside documentation), is to typehint your parameters. But when you do so, you are no longer able to overload your methods anymore. Because of this, I think this feature is EXTREMELY relevant to solving the web problem. Not being able to overload methods anymore is a bad thing since overloaded methods allow to use a class in much more situations than just being able to use it in one single way. You are not able to tell the developer to use integer OR string values but NO arrays, booleans, Objects and so on when calling your method. You could mention it in the comment but when he misunderstands the comment, php doesn't notify him about his error. When using type hinted parameters, php would do so. You are not able to provide strict api's out of the box right now. You will always have to check the types of the passed parameters manually.
