The sentiment here seems to be overwhelmingly positive. Call me a cynic, but this reminds me of "magic_quotes" all over again: a "feature" that tries to help, but masks the fundamental problem.
What is the fundamental problem it masks?
XHP: A New Way to Write PHP (from Facebook)
31–40 of 72 posts
Re: XHP: A New Way to Write PHP (from Facebook)
#32BTW for those of you interested in installing on Linux, you'll need php5-dev (so on deb/ubuntu machines a quick apt-get install php5-dev solves it). Run phpize from the root, then the normal ./configure, make, make install etc...
has anyone gotten this to work on OSX? I get strange errors after I build and add the extension to php.ini LOG: http://pastie.org/817528
I have so many damn unnecessary problems with OS X that I've resorted to running a lightweight Debian VM with VMWare. It uses ~250mb out of my 4GB RAM and I can just suspend it whenever I'm not coding.
Benefits: I can use apt-get and have all the other conveniences of a true *nix environment. I can update and try out new software easily (I had XHP running in about 5 minutes). Also, I can create snapshots of my OS so that when my environment is just the way I like it, I can always revert right back to it.
I interact with certain paths on my virtual linux filesystem just as though they were local (like my ~/Sites dir) and have various dev domains in my /etc/hosts file pointing to the VM (which has it's own internal ip).
Cons: It's a standalone VM so it consumes a consistent 250mb of memory. Never really looked at what mysql/apache were doing on my Mac previously (I would assume far less) but I haven't really ran into an issue where the VM is a big issue yet. The convenience far outweighs the chuck of memory it eats up :)
I haven't had a single configuration problem yet ;) For developers the popular phrase is reversed, Debian "just works" and OS X is a pain in my ass.
Re: XHP: A New Way to Write PHP (from Facebook)
#33Earlier quoted context omitted.
Saving 14 bytes per request is something only a very few sites need to think about... For the rest of us, clarity and semantically correct code are much more useful.
Wasn't there just a thread complaining about how the end tags make HTML so much more verbose and difficult to read, and that's why people are writing preprocessors like HAML and XHP? I've found that the code is much clearer when you omit your end tags. As for semantic correctness - it's in the HTML spec, and every major modern browser handles it correctly. Sometimes I wonder if Google's the only folks who actually re…
SGML is fun. It looks like XML, but is way crazier.
Re: XHP: A New Way to Write PHP (from Facebook)
#34[deleted]
Re: XHP: A New Way to Write PHP (from Facebook)
#35XHP rocks so fucking hard, it isn't even funny. It is just so much better than alternatives. IMHO, It is the only PHP tool I use at facebook that is better than alternatives in other languages. I'm looking at you, django templates! The notation perfectly represents the objects, with no cruft associated with object oriented programming. That is really rare. You could argue that the markup syntax is cruft, but it reall…
Couple questions: 1. How is this different from Django filters? Is it that the default is HTML escaping instead of having to specify the escaping with each template variable? 2. How does it handle different escaping contexts? For example, text in html attributes needs to be escaped differently from text in the body of the document. Text in URLs or JavaScript has to be escaped differently still, and often times you ha…
I'm also very interested in how it is able to escape properly... anybody?
Re: XHP: A New Way to Write PHP (from Facebook)
#36The sentiment here seems to be overwhelmingly positive. Call me a cynic, but this reminds me of "magic_quotes" all over again: a "feature" that tries to help, but masks the fundamental problem.
What is the fundamental problem it masks?
The separation of presentation and logic.
Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.
Re: XHP: A New Way to Write PHP (from Facebook)
#37maybe I've misunderstood, but this seems to advocate mixing inline HTML and php logic - isn't that a huge step backwards in terms of web software architecture? I thought we were all using the MVC model by now... My head just hurts thinking how utterly unmaintainable all that spaghetti code must be.
Not really. You can still separate MVC style. Templates have always had some display logic, which is ok. What you don't want is intermixed application logic.
In my opinion this "fuzzy" separation is exactly what frameworks like Django (and many existing PHP MVC frameworks) tries to avoid - they specifically disallow things like arithmetic in their templating language for this reason. As soon as you get more than one person working on a site, you're going to have an overly ambiguous demarcation point between the presentation and the logic layers and it's going to wreak havoc on the development process. It will take an enormous amount of discipline to have a parallel design/code workflow.
Does this offer any benefits to XML comprehension beyond syntactical sugar to allow echo avoid the use of quotes and to remove the god-awful syntax (which puts it at par, at the very best, in my opinion)? Does it handle XML syntax errors gracefully? Can you do native transformations on bound variables, for example, or do any more sophisticated XML DOM-ish tag functions? The post doesn't mention anything about any of these issues, which is where the real advantage would lie. If any of that were possible, you could put the browser DOM (and validation) one step closer to the application logic. As far as I can tell this just attempts to ambiguate the VC in MVC, where Django tries to replace V with T (template).
As far as I'm concerned this only increases the squinty-eyed "WTF" factor between PHP and other languages.
Re: XHP: A New Way to Write PHP (from Facebook)
#38The sentiment here seems to be overwhelmingly positive. Call me a cynic, but this reminds me of "magic_quotes" all over again: a "feature" that tries to help, but masks the fundamental problem.
What is the fundamental problem it masks?
Presumably he means allowing users to thoughtlessly work with unsafe values. One way that XHP could mask this problem is clear by looking at:
echo {$_POST['name']};
echo $_POST['name'];
If PHP gave all unsafe values the type "unsafe string" and disallowed all implicit conversion to safe types, then XHP's approach would be a welcome way of doing the right thing by default. Programmer-introduced errors like the above example would result in fatal type errors instead of exploits (presuming "echo" won't take unsafe strings and so requires a conversion function, like htmlspecialchars or the hypothetical unsafe_cast).
Re: XHP: A New Way to Write PHP (from Facebook)
#39Earlier quoted context omitted.
What is the fundamental problem it masks?
The separation of presentation and logic. Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.
That seems to be unrelated to the concern here (as belied by the grandparent citing magic_quotes). XHP (like plain PHP, for that matter) can be used in a way that, for all intents and purposes, separates the concerns of presentation and logic. It's more a matter of convention than constraint.
Re: XHP: A New Way to Write PHP (from Facebook)
#40Earlier quoted context omitted.
The separation of presentation and logic. Anyone who's spent the 1990s coding Perl CGI will tell you just how big of a step backward this is.
That seems to be unrelated to the concern here (as belied by the grandparent citing magic_quotes). XHP (like plain PHP, for that matter) can be used in a way that, for all intents and purposes, separates the concerns of presentation and logic. It's more a matter of convention than constraint.
> separates the concerns of presentation and logic
WHAT? The explicit purpose of this is to combine the presentation (HTML) and logic (PHP) layers.