PHP Gets Namespace Separators, With a Twist 523
jeevesbond writes "PHP is finally getting support for namespaces. However, after a couple hours of conversation, the developers picked '\' as the separator, instead of the more popular '::'. Fredrik Holmström points out some problems with this approach. The criteria for selection were ease of typing and parsing, how hard it was to make a typo, IDE compatibility, and the number of characters."
yet another wtf (Score:3, Interesting)
The rfc [php.net] claims that typing "**" is easier than typing "%%" or "^^".
Re:WTF? (Score:5, Interesting)
You should say "thanks" they haven't chosen something else. e.g Jam (build system; make analog) uses "!" as a "platform neutral" path separator. During evaluations for new build system I joked that I oppose jam since we do not need a "platform neutral" system - we need one for *nix and cygwin. To my surprise many supported me.
I think their decision to use '\' is very very dumb one.
I'm still huge fan of Objective-C in that aspect. Unlike C++, which tried to marry C and objects, ObjC took more pragmatic approach: C constructs remains C constructs and object oriented constructs got new distinctive syntax so that you can never mix up what code you are looking at.
In that aspect, I think PHP folks would regret their decision in future: '\' isn't distinctive enough and they would need to introduce more silly syntax hacks when extending language further.
Re:Well, That Does It! (Score:2, Interesting)
This isn't the first (or last) time PHP developers have implemented a stupid workaround rather than fixing problems with the language/runtime/interpreter/parser/scanner.
.NET / WPF is going this way (Score:3, Interesting)
At least in a sense. You can map a .NET namespace to an XML namespace. Say you have namespace that is:
Shados.Awesome.Controls
You can map that into:
http://www.shados.com/controls
In c# you'd plunk this into your AssemblyInfo.cs file:
[XmlnsDefinition("Shadows.Awesome.Controls","http://www.shados.com/controls")]
And thus add it to your XAML code:
<UserControl xmlns="http://www.microsoft.com/xml/something"
xmlns:shadow="http://www.shados.com/controls">
<shadow:AwesomeControl x:Name="myControl" param="aParam"
</UserControl>
You can even get multiple .NET namespaces to map into a single XML namespace.
Re:Today is a Wonderful Day (Score:4, Interesting)
Other suggestions (Score:3, Interesting)
For additionnal fun, read this: http://wiki.php.net/rfc/namespaceseparator [php.net]
Looks like they considered stuff like :> and :) as separators for namespace. Seriously.
Also, they don't give any malus for tybe-ability to \ while on most european keyboards it's a lot harder than any other suggested separator. Way to go !
Re:The BASIC of the 21st century (Score:3, Interesting)
Re:so what's the problem here? (Score:3, Interesting)
1) "/" - used by almost all languages in regex expressions. I wouldn't want to pollute that namespace.
2) "::" - Awesome. Many other languages do this. I think this is already taken for PHP, but I dont know PHP well enough
3) "|" - Pipe has a very specific meaning on the command line and I'd hate to pollute that. Plus it looks ugly.
4) "~" - Any reasons this wouldn't work?
5) "." - Again, awesome. Many other languages use this.
6) "!" - Used
7) "&" - Ugly, used.
8) "," - Why not? Does any language use the comma for anything? Might be kinda ugly though "$var = My,Class($arg1);"
Re:what wrong with (Score:2, Interesting)
The backslash isn't used for anything except escaping strings, and I doubt that's going to add any ambiguity at all.
Oh?
What's this going to mean?
namespace X;
class n{
}
$X\n->r = "B";
Then later....
$X="S";
echo "$X\nn->r\n";
Doing string interpolation unambiguously will be a PITA, since \ has special meaning inside a string.
Does the "\n" delinate the end of the identifier and a carriage return, or is it being used as a namespace separator?
I don't think they're making parsing all that easy.
At least with lexical rules and a . operator, things can be well-defined, and not break other features of the language.
Re:Easier on which keyboard layout? (Score:3, Interesting)
I couldn't agree more. When I read this my only thought was "what the fuck?". On a German Mac keyboard, \ is Alt+Shift+7. I think on Linux and Windos it's something equally retarded.
Will the people who made PHP a good programming language please fork it and take it away from the clueless morons who have taken over?
Re:what wrong with (Score:2, Interesting)
<?
class Q{
};
$Q->n="B";
echo "$Q->n\nS";
echo "$Q$Q+$Q\nX->n\n";
?>
And the output in PHP 4.4.8 (version of PHP distributed in stable OSes) is:
B
SObjectObject+Object
X->n
Just like one would expect....
Re:It's all a joke (Score:3, Interesting)
'**' is easier to type than '^^'?
It is, once you consider some people have dead keys. Typing "^^" can become wildly different depending on what OS you're using, and result in weird behavior. On some systems/applications, the two carets are printed at once and you're back to normal editing. On others, the first one is written, but the other remains in dead-key mode. I've seen systems where this would just print a single caret (possibly coupled with a beep). Then the only reliable way on those keyboard layouts to type that symbol is to press caret, space, caret, space -- four key presses (not counting any shifting you might need to get to the caret character) for an operation which might become very common.
Using '\' has the best parse-ability?
Well, an unambiguous, single-character token is often easier to parse than a double-character token which might conflict with a single-character one.
Plus they did not even evaluate '::'.
That's what they were originally using. The problem is that they already use it for static method invocation, so there would be problems when class names and namespaces clashed. And then for some reason they decided they wanted to allow that to happen, rather than (for example) not allowing classes to have the same name as namespaces and mitigating that by using different naming conventions for both.
But then again, the backslash isn't very easy to type either -- I'm daily switching between three different computers. On each one of them, the backslash key is in a different position. Seriously.
Re:WTF? (Score:3, Interesting)
Not at all, there were some serious ambiguity issues that needed to be resolved.
Take the following code:
----------
# first file
namespace Foo;
function blarg()
{
echo "function";
}
# second file
class Foo {
public static function blarg()
{
echo "method";
}
}
# third file
Foo::blarg(); // what does this output?
-------
The problem here is that calling a static method and calling a function within a namespace share the exact same syntax, so at a glance you can't be sure what will happen.
If we assume that PHP internally does its lookups in these situations as function first, then class, then there's four possible scenario's in this situation.
1. You have both files included at once, PHP gives a fatal error due to the ambiguity.
2. You only have the first file (namespaced function) included, so it outputs "function".
3. You only have the second file (static class) included, so it outputs "method".
4. You have neither files included, but you have defined an autoload method which loads your static class file and outputs "method".
Obviously the ambiguity is a serious issue, so you need to resolve it somehow. Either you make a special syntax for calling functions in namespaces, you change namespaces so they can only be used for classes, or you change the seperator for namespaces to something else.
Re:That's because.. (Score:2, Interesting)
I don't know what you mean by "weakly typed language" as it has several different meanings*, but I think being or not being weakly typed doesn't have anything to do with it.
The fact is that PHP automatically and forcefully converts operands into the correct type with the '+' operator (is this what you mean by weakly typed?). That is, "5" + 5 = 10, so all operands are converted to numerics.
Incidentally, Java, will do this the other way, as "5" + 5 = "55". All operands to + get converted to String ("5" + obj is the same as "5" + obj.toString). Curiously, nobody is quick to call Java a weakly typed language.
The exception, in Java's case, is the rule that + will always concatenate:
5 + "5" = 55 // Java // Java // Java
"5" + 5 = 55
5 + 5 + 5 + "5" = 155
Any time a String is encountered, Java will decide it is a concatenation operation (never addition). If you want to use the + operator for addition, you'll have to make sure all the operands are of some numeric type.
For PHP, the original developers decided that it would be much more useful to always be able to add instead of concatenate. For example:
"b" + 5 = 5 // PHP; b gets converted to numeric value of 0
Of course, they could have the opposite rule so that if a numeric is present, then you must add; otherwise the operation is a concatenation. My opinion (and theirs probably) is that this rule would be terribly confusing, so they used the . operator for concatenation.
On the flip side, my opinion is also that having "b" + 5 evaluate to 5 is also terribly confusing! There was nothing stopping them from making PHP behave like Java in this case (and still have PHP be "weakly typed", whatever that means).
Unfortunately, it's way too late now, as there is already a ton of code exploiting this messy design decision.
* Some people take weakly typed to mean types are associated with values instead of variables, for example.
Wonderful analogy! (Score:4, Interesting)
Spot on. Dead on target and a car analogy. You rock.
--MarkusQ
Re:I have to say they are working really hard.... (Score:3, Interesting)
CGI days (only technical requirement is standard input and output) are long gone.
Well, not really. It still works. Your biggest complaint:
You gonna end up with huge performance problems unless you would use something more modern and advanced than trivial piping.
That is a vertical scaling concern. If vertical scaling is that important to you, consider using C, instead.
Not that it's unimportant. I'm just saying -- if all we had was CGI, there's no reason we couldn't still throw hardware at the problem.
No, I was talking about things like FastCGI, or even more relevantly, in-application webservers. It turns out, talking HTTP really isn't that hard. Ruby has, by my count, six separate in-application webservers supporting the common Rack API.
Throw a load balancer like nginx in front of them, and what do you need Apache for? Other than old apps which were tied too closely to it -- some mod_php (though those mostly tend to work with php as fcgi), and especially some mod_perl -- but that's about it.
In other words: HTTP itself is the new CGI. And that still gives you plenty of flexibility about what you choose for an implementation language.
Now you already can't choose/change language easily as you could in past. Service libraries and frameworks - as per project requirements - pretty much define what language one would use.
Not many project requirements dictate specific frameworks -- and they shouldn't.
Services, maybe, but honestly, any service that needs such a huge library that you wouldn't port it to a better platform is too complex a service, and also too rigid a library.
Re:Another fashionable addition for PHP: (Score:2, Interesting)