Slashdot Mirror
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."
... and comming full circle.
Onda Technology Institute
PHP 5.3 also adds support for local GOTOs. This langauge is so up with the times.
I couldn\'t read the summary because it had an unterminated string literal.
It'll be /, just to keep things interesting.
...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
The rfc claims that typing "**" is easier than typing "%%" or "^^".
Do you even lift?
These aren't the 'roids you're looking for.
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
[sic]
The World Wide Web is dying. Soon, we shall have only the Internet.
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?
Just make sure they name it a backslash in the documentation, not a slash.
... to cause for windows servers...
imagine what directories will be deleted due to a typo!
Maybe they could starting fixing the noun-verb vs verb-noun problems instead.
Selling software wont make you money, selling a service will.
The number of days that an old, crusty Perl developer can laugh at another language are few and far between.
Thank you, PHP.
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.
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.
All hope abandon ye who enter here.
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.
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.
Do you even lift?
These aren't the 'roids you're looking for.
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
Except you just made a typo. It is "\" instead.
Either way, most languages use either "." or "::" for namespaces
# perl looks like
use My::CPAN::Module qw();
my $instance = My::CPAN::Module->new("junk");
# c# looks like
using System.Windows.Controls;
System.Windows.Controls.ListBox box = new System.Windows.Controls.ListBox();
# c++ looks like (I think)
namespace Blah::Blah;
# php will now look like
$object_instance = new My\PEAR\Module("myvar");
I'll leave the "looks" of PHP's method to the reader.
Looking at the IRC discussion it seems that they didn't have much of a choice.
PHP uses the . as the concatenation operator. PHP does not support operator overloading...
You don't need operator overloading. To use the same symbol in different contexts.
You need a parser worth its salt.
a.one = $b.two . $a.one
Only has one use of the concatenation operator if 'a' and 'b' are namespaces.
A good convention is to simply require space around the concatenation operator. Or to require both operands meet the lexical conventions of a variable or string constant, for it to be interpreted as a concatenation.
I.e. $X = $A . $B
Is a concatenation
$X = $A.$B
Is a parse error
$X = $A.B
Is an assignment of 'X' to the 'B' variable within the 'A' namespace
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.
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.
The problem is not merely that it is different.
The problem is they chose the ESCAPE character as a namespace separator.
This is even worse than using $ as the namespace separator.
Because of the problems it causes syntax highlighters, the problem it causes to programmer sanity when storing identifier names in a string.
The problem it causes when searching through and sanitizing code.
For example, since \ has a special meaning in the context of a regular expression, searching and replacing using regular expressions just got very painful.
Copy and paste no longer works for searching and substituting.
Refactoring just became a major bitch.
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.
For additionnal fun, read this: http://wiki.php.net/rfc/namespaceseparator
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 !
When are you going to use the escape character outside of a string? I agree that it's dumb, and it's going to make for ugly looking code, but saying that it shouldn't be used because it's an escape character seems like an empty criticism. It's like saying that Elisabeth Taylor's personal life is messed up because she doesn't pay enough attention to her hair.
Now do you have to escape your namespaces before passing them through eval?
eval("$instance = new My\\Super\\Class(\"blah\"););
Since they now are using the escape character for namespaces, I wonder what kinds of security implications this might have? What happens when a PHP program for some reason evals() some user input that doesn't properly escape the namespaces?
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);"
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";}
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.
Since PHP is open source, someone will make a fork with a different separator and the dumber of the two choices will wither away.
It's simple: I demand prosecution for torture.
As I remember, everything more complex than just outputting the value of the variable (ie calling a method, accessing a property, etc) requires you to use brackets inside of the string. Namespaces would work the same way without adding any complexity that wasn't already there.
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.
Give Haskell (or ML, Scheme, Lisp and friends) a try: using PHP to prototype algorithmically intrincate stuff is simply absurd.
<?
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....
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.
'**' 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.
:: 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.
Yeah, screw those guys! I'll make my own PHP -- with blackjack! and hookers!
Soylent Green is peoplicious!
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.
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!
calling a computer programmer a "software engineer" is like calling a crack whore a "courtesan".
There's no "engineering" involved for ninety nine percent of them.
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
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.
Yes but we are talking about a very, very slim minority here are we not? No offense intended but it seems like your whole point is hinging on the absolute minority of people out there. I can't think of any systems off hand that do this
According to Wikipedia, the circumflex accent is "used in written Croatian, Esperanto, French, Frisian, Norwegian, Romanian, Slovak, Vietnamese, Romanized Japanese, Romanized Persian, Welsh, Portuguese, Italian, Afrikaans, Turkish and other languages".
I don't know the keyboard layouts used by all of them, but I'd bet most (if not all) of them use a dead key for both the caret and the circumflex rather than including additional keys, and Portuguese and French have a reasonable number of speakers. Plus there are those who, despite not speaking one of these languages, still have dead keys (for example on US-International). What's the layout used by the people who speak Spanish in the US? If it's US-International, that should be a sizable part of the population even in an English-speaking country.
So spend the $5 and get a new keyboard?
Um, no, not always possible. I know this comment went more into my particular problems, but still I saw similar complaints on Reddit. I guess people in other countries also have the same issues of every now and then having to deal with other layouts.
And this is (one of) the many reasons PHP sucks:
Java:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Package access: foo.bar.baz
C#:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Namespace access: foo.bar.baz
Python:
Attribute/Method access: foo.bar
Static method access: Foo.bar
Module access: foo.bar.baz
PHP:
Attribute/Method access: $foo->bar
Static method access: Foo::bar
Namespace access: foo\bar\baz
But... the future refused to change.
Spot on. Dead on target and a car analogy. You rock.
--MarkusQ
In fact, not to start a language war, I think his language of choice should be Perl.
Cheers,
alf
"People with laptops" is a very, very tiny minority?