PHP Gets Namespace Separators, With a Twist
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."
PHP 5.3 also adds support for local GOTOs. This langauge is so up with the times.
...to make PHP the most retarded computer programming language on the planet.
It takes a man to suffer ignorance and smile
Be yourself no matter what they say
As a developer who primarily works with C#/.Net, with a little PHP on the side, IMO this addition is long overdue. It would be nice to have a more standard separator, but when I RTFA they seem to have a just reason for it, and it's using semantics that PHP coders are used to. I will happily adjust myself in this ONE manor in order to reap the MANY benefits of namespaces.
Just my 2 cents.
Where genius and insanity become confused true wisdom is found
PHP uses the . as the concatenation operator. PHP does not support operator overloading...
Username taken, please choose another one.
I once did a lot of work on PHP. Today, when people ask me for upgrades I just migrate it to Python.
This unfortunate choice of the escape character for namespace separator is stupid, but seems almost irrelevant to me. How many nails do they need in the PHP coffin to bury it?
Maybe they could starting fixing the noun-verb vs verb-noun problems instead.
Selling software wont make you money, selling a service will.
It's not just developers, it's things like IDEs which highlight anything starting with '\' as an escape sequence.
Which - since nearly every other common programming or scripting language uses '\' to mark the beginning of an escape sequence - is something you might reasonably expect.
Come to think of it, so does PHP... ooops...
Il n'y a pas de Planet B.
How is it possible for even American developers to be this clueless. Which characters are convenient to type depends entirely on the keyboard layout that is used. Case in point, $ is insanely painful to type on Scandinavian layout.
If your choice of characters used in your programming language is affected by how easy/hard it is to parse the code, you probably shouldn't be involved in developing a programming language.
I think their decision to use '\' is very very dumb one.
You've summed up my opinion concisely. That is *truly* retarded to use the (almost?) universal escape character for another reason. Almost as retarded as Microsoft going with \ for a directory separator.
Get your own free personal location tracker
Since PHP is a weakly typed language, using + for string concatenation would introduce a number of problems. + is used numeric addition, and thus automatically converts the operands to numbers before adding them.
So using + for string concat too would be basically impossible... When would you decide to concat the operands, and when would they be added? If you base it on the results of the string to number conversion, you get situations where the same line of code sometimes adds numbers and other times concatenates strings, or where it is impossible to concat two strings which contain only digits.
Scripting languages are for those of a weak mind and poor technical skills and the singular lack of the ability to plan a system out before you write one line of code.
Or for projects that need to be compiled at runtime. But, nice magnanimity.
Geez, you have a website that just mirrors Wikipedia and dumps google ads all over it? You must be some kind of a business genius. Particularly since you seem to think that spamming /. will get you clicks. Bandwidth usage and hatred maybe, but clicks, nope.
The whole purpose behind using '.' as string concatenation instead of '+' is that it eliminates ambiguity. What you're suggesting throws the ambiguity back in. Remember, if it's more complex for the parser to understand, it's more complex for a human to understand. As a programmer who moves between PHP and Javascript a lot, I can tell you that I miss being able to use a dot for objects when I'm in PHP, but the ambiguity in string concatenation/addition in javascript is an order of magnitude more annoying.
I suspect they're doing the same thing with namespaces. The backslash isn't used for anything except escaping strings, and I doubt that's going to add any ambiguity at all. There are a lot of problems with PHP, and it's well worth your ridicule, but making sure that separate operations have separate operators isn't one of those problems.
Calling a variable "myInt" doesn't make it an integer -- it was a float from the second you added a dot.
First, duh. Second, are you sure it will return "hello1.0" and not "hello1.00" or "hello1"? I'm not, I could test to find out, but that makes my point. It adds ambeguity to the language and makes me think about something I really should be thinking about. To use your example, what does the following result in?
function blah(arg1) {
var blah = "10" + arg1 + 5 + "hi";
}
alert(blah("hi"));
alert(blah(1));
alert(blah("1"));
My example isn't as contrived as yours. What if blah() was in some other JS file. It could be easy to trip the function up based on what you pass in.
Using "." for string concatenation at least gives both you, the code reader, and the compiler a hint at what you mean. That way the compiler can barf if you do something silly like concatenate an integer with a string. Using "+" for both addition and concatenation just makes more work for both parties.
In any case, I don't find concatenation nearly as useful as interpolation, most of the time. In Ruby, at least, interpolation is known to execute faster than concatenation. But that doesn't help you if you're using JavaScript.
I agree with this statement. I much prefer how Ruby and Perl do it... just toss the variables into your string and it will interpolate them.
BTW, I'm not too familiar with Ruby. Does it pull the same trick Perl does and use a different operator for string comparison?
if($myStr eq "hi") { print "hi";}
Why, exactly? English is not the only language spoken in the world, you know, and programmers in many countries feel more at ease naming identifiers using their native language rather than trying to come up with an English translation with their limited knowledge of English. In fact, when people who don't know English well are forced to use English names in identifies, the mistranslations that result can often be very confusing - take it from someone who has to deal with such code daily. And most languages in the world require at least a few letters not in ASCII.
By the way, have you seen Fortress programming language? You know, the one that not only allows Unicode, but uses its fully in the core library, including all standard mathematical operators (with their normal meaning). It is surprisingly readable.
Unicode is used throughout for several years now. Programming languages are pretty much the only place where ASCII still holds, but ever since Java, this has been relaxing more and more - and rightly so. Look back 30 years - do you remember all that code written in all-uppercase because many computers of that time simply didn't have lowercase letters? And it's all gone now, because there's no longer any need to account for such machines - they don't exist anymore. Restrictions on plain ASCII only are heading the same way, and for the same reasons. All editors support Unicode now, so it is used already, and it will be used more and more.
So how do you like scamming your ads off of Wikipedia's content ?
Just when I thought the human race couldn't get any more pathetic, I get proven wrong.
-Billco, Fnarg.com
Given that / support has only been present in recent Windows versions, I have to say
[citation sorely needed]
This sig is part of your complete breakfast.
You'd have to do that anyway, because you used double quotes, "$instance" is going to get evaluated and your eval will fail anyway.
:: is already used for static methods on classes... it would be harder to implement the differentiation of :: for namespaces and :: for static methods... especially if people started to use classes with the same name as a namespace (which is likely if all modules get their own namespace)
I actually think that '\' is appealing for what it will be used for. The one thing I first though of was SomeModule\new_object::test_function();
Wouldn't it try to evaluate the '\n' as a \n new line? I suppose it will be out of the double quite string scope so it could be alright... could get messy if eval()-ing code, though.
with 4GB RAM machines with TB hard drives - and we're still worrying about "the number of characters".
Oh, please. Fucking nerds.
For the last forty years, we've been constrained by one pointless limitation after another, not to mention the complete inability of a PC to discern what is an identifier and what is command syntax if it has fucking SPACES in it.
Get your heads out of your asses.
And learn to type.
"Number of characters" - Jesus Baron von Christ!
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
Yeah, and if you are running PHP on a Windows server, do you really need any more trouble?
sic transit gloria mundi
"People with laptops" is a very, very tiny minority?