Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP 7 deployment at Dailymotion

engineering.dailymotion.com

Post reply on HN
Print view View original

51–60 of 166 posts

Re: PHP 7 deployment at Dailymotion

#51

Post by cjhanks »

haimez wrote: post #47
cjhanks wrote: post #45

Earlier quoted context omitted.

That scope logic is normal in many interpreted languages. I love it in Python.

Python does support block scoping- so no- it doesn't work there. Also, if you need to use variables in outer scopes, it's ok to declare them there. There is literally, and I mean this, literally- no possible justification for using inner-scoped variables in an outer scope that they weren't declared in.

if predicate: A = 3 else: A = 5

B = A / 2

...

Why forward declare A = None?

Re: PHP 7 deployment at Dailymotion

#54

Post by haimez »

cjhanks wrote: post #51
haimez wrote: post #47

Earlier quoted context omitted.

Python does support block scoping- so no- it doesn't work there. Also, if you need to use variables in outer scopes, it's ok to declare them there. There is literally, and I mean this, literally- no possible justification for using inner-scoped variables in an outer scope that they weren't declared in.

if predicate: A = 3 else: A = 5 B = A / 2 ... Why forward declare A = None?

Because it announces that you intend to use the name 'A' in the current scope after some assignment happens in a nested one. It's intentional.

It /can/ be useful, but it should be opt-in. JavaScript had to figure this out with their 'var' declaration scoping too.

Also, try:

A = (predicate) ? 3 : 5

Or, in a language that embraces expressions instead of statements:

val A = if (predicate) { 3 } else { 5 }

These are all more intentional, concise, and readable than allowing variables to outlive their scope by default.

Re: PHP 7 deployment at Dailymotion

#55

Post by kijin »

> In other languages you can't get that without using a standard library that will escape the values by default.

Escape for what context?

Escaping for SQL is different from escaping for HTML, which in turn is different from escaping for JS.

How does your hypothetical Request object know how to escape any given variable? Does it ping every open database handle to figure out how they want their data escaped? Does it use some kind of static analysis to figure out in what format (HTML? XML? JSON? CSV?) the app is going to spit out the value later on?

Or does it simply run a bunch of cargo-cult functions like

    return htmlspecialchars(strip_tags(mysql_real_escape_string(addslashes($_POST['var']))));
and hope that everything will be okay?

Re: PHP 7 deployment at Dailymotion

#56

Post by kijin »

unabst wrote: post #43
Akujin wrote: post #38

Earlier quoted context omitted.

I don't get why people keep harping on super globals are being inherently bad. The variables are there. You can use them or ignore them. A variable definition harms you in no way other than a tiny bit of memory usage which is capped by the HTTP limit on POST and GET limits anyway. What? You think you're gonna get hacked because $_POST['ihaxyou'] is set to 'w00ts'? No one does this anymore: mysql_query("SELECT * FROM…

In all seriousness, shouldn't all the frameworks just have some validation built in? Being that this is such a "global" WTF problem. I would love to be able to say ini_set('sanitize_rest', true) and deal with errors that might result from that knowing at least the strings are safe. Or have functions like sanitize_string($str) and have the documentation encourage it everywhere. I mean, aren't we all just implementing…

PHP has already tried automatic sanitization with magic_quotes_gpc, and the results were far from secure.

It is not possible to have a single sanitize() function that renders a string safe for every possible context, and to try to provide one results in nothing but complacency and false sense of security.

Escaping for SQL is different from escaping for HTML, and even if you escaped a string for both, some idiot is going to echo it inside an inline script or a CSS attribute. Sanitize for all of them, and you begin to seriously mangle those strings. Oh, and it might still be ineffective against directory traversal. I've seen plenty of PHP users who think they're clever because they wrote a function that applies every single escaping function in a row, not realizing them some of them undo one another's work. Selectively unescaping after the fact is even more fun.

The only thing I can think of that could render a string absolutely safe in every context is intval(), but then you don't have a string anymore, and I suspect that even that can be abused with unexpected zeroes and negative values.

Re: PHP 7 deployment at Dailymotion

#57

Post by jpgvm »

mastazi wrote: post #50
jpgvm wrote: post #31

Earlier quoted context omitted.

As I said, by all means you can write bad code in good languages. I'm not saying choosing a good language excludes all possible bad code, only that they provide some guidance on better practices. So you mention Java. Java enforces OOP. Now OOP may not be the best paradigm always, however its a vast improvement on inline procedural PHP. That isn't to say you can't write some horribly modelled Java code, but the fact t…

> by all means you can write bad code in good languages I think the main criticism of the GP was the fact that you use the expression "good languages" without defining what makes a language "good". > not be the best paradigm always same as above, what makes a paradigm "best"? > vast improvement on inline procedural PHP. but why you assume that the majority of PHP codebases are written in an "inline procedural" style?…

You are missing the forest for the trees.

The statement I made is that more consistent and "opinionated" languages encourage better code. They don't enforce it, just encourage it.

It is my opinion that this is valuable.

I did define "good", internally consistent languages with strong guidelines for developers. I made no statements about mature PHP codebases as they are irrelevant to my argument. I do accept that people prefer less "opinionated" languages, I too fall into this camp, but I am no longer a new developer, as such this point is entirely irrelevant to what I was saying.

Nitpicking individual points whilst misconstruing what I said is neither useful or appreciated.

Re: PHP 7 deployment at Dailymotion

#58

Post by tedmiston »

skrebbel wrote: post #53
tedmiston wrote: post #52

> During few months, this project wasn’t the priority, so we decided to wait the release of PHP 7 to compare performances. I have no idea why the author is choosing to write in such a strange grammatical style.

If you have no idea, why bring it up?

Often times other people here do have a different perspective.

I also found it very distracting from reading the post.

Re: PHP 7 deployment at Dailymotion

#59

Post by wvenable »

vcarl wrote: post #39
wyager wrote: post #21

Earlier quoted context omitted.

>As a JS/Web developer you learn to ignore the hatred of the web that it seems to get from the HN crowd. As an occasional full stack developer (not by choice), I can confidently say that the reason people hate on popular web tech is that it is uniformly terrible compared to non-web tech. I'm no fan of Java, for example, but I'll take it over PHP any day. JavaScript is so bad that I (and many other developers) will pu…

This is the typical "hatred of the web" that I usually ignore. ES2015 brought a ton of huge language improvements that are still filtering out into usage, Babel means you can use them all now without waiting for browsers to implement them, Webpack gives you a ton of flexibility for packaging it, Eslint allows you to lint in a completely pluggable way, NPM (and now Yarn, which fixes many of NPM's problems at scale) al…

The length of that paragraph and the number of tools mentioned is exactly one of the problems of web development. It's like missing the forest for the trees. And even with all the huge language improvements, it's still no where near the capabilities and safety of non-web languages.

But I don't disagree that it's possible to write very high quality JavaScript code -- it's just a little bit painful.

Re: PHP 7 deployment at Dailymotion

#60

Post by kyriakos »

Akujin wrote: post #49
wdewind wrote: post #41

Earlier quoted context omitted.

> Contrary to the hive mind you don't need some special encapsulation class to pull your post and get variables. The hive mind is like that for a reason. Making it easy to do the right thing and wrong to do the wrong thing has massive effects, I'd argue the magnitude of which scale exponentially with the growth of an engineering team. Really really talented engineers make mistakes all the time. To the extent that we…

I think people are also confusing an old issue from PHP 4.x where if you had $_POST['somevar'] it would actually have an alias automatically set as $somevar in the global userspace. This was turned off by default a long time ago and is the main real security issue when it comes to super globals. $_POST and $_GET are just the normal way to access POST and GET vars. There's nothing inherently insecure about it.

Exactly, this is where the real problem was and thankfully it was fixed. An attacker could insert any variable in a script just by adding it to the URLs additionally the PHP configuration could change variable order the variables from different sources were given so a script essentially didn't know where it was getting the information from. On the other hand the super globals are just a utility making things easier for the developer, they don't directly make code insecure.
Post reply on HN