Making PHP Safer • Hacker News Board

Re: Making PHP Safer

#41

Post by pekk » Sat, Feb 01, 2014, 3:11 AM UTC

kijin wrote: post #33

Type hinting for scalar types has been on and off the TODO list for PHP for a while now. PHP already has type hinting for arrays and objects, but not for scalar types like int, float, and string. It's been on the roadmap forever but nobody seems to know when the feature will actually land in a stable release. That's because type hinting for built-in scalar types is more difficult than it sounds in a dynamic language…

If the function requires an integer, it is an error to pass a non-integer. Everywhere outside PHP, including in dynamic languages, this is not a hard decision

Re: Making PHP Safer

#42

Post by encoderer » Sat, Feb 01, 2014, 3:13 AM UTC

jazzdan wrote: post #23

encoderer wrote: post #12

Reading this, wishing Facebook's Hack lang was OSS so I could really have a chance to sink my teeth in and compare/contrast these tools. Edit: Clarity

Facebook's Hack lang is open source, though not publicly documented. This commit points out a lot of the implementation and test files: https://github.com/facebook/hhvm/commit/db9577b1409b74293fd9...

Fascinating! I had no clue.

Re: Making PHP Safer

#43

Post by ciarand » Sat, Feb 01, 2014, 3:24 AM UTC

wvenable wrote: post #36

ciarand wrote: post #35

Earlier quoted context omitted.

First, you're right - the core library and API does have a long way to go. Imo, we need a new major version (6) so we can break backwards compatibility for some of this craziness. But as for the annotations, the most compelling argument I've seen is to make it string (===). If you supply "123" and the method signature requires an int, it should throw an exception. If you don't want that, don't include the typehint. T…

I disagree. Strict type hinting would be ridiculous in PHP and lead to a lot of unnecessary and unsafe casting. nikic goes through all the scalar type hint options here: http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-har... Strict weak type hinting seems like the most realistic and pragmatic choice except I would add a cast to make sure the type is actually an `int` in the function.

I've read that article, and like most of the commentators I'd like the option for strict type hinting. It's a choice I make, it's not forced on me. Having strong type hints removes any doubt from the code. I know exactly what's being passed around and what it represents, and I can be comfortable in knowing what that means. I don't need the engine to do anything magic[1] in the background.

While the idea of "strong weak type hinting" is interesting, and would certainly be useful for some code (especially libraries), it's not what I want from type hinting. At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it. That's not a behavior I want, that's something I want caught before I even think about deploying.

I guess it depends on what you expect type hinting to provide you, but it looks like I'm not alone in wanting guaranteed safety (Facebook and Box seem to agree). Only strict typehinting fixes that.

But, if the community decides that SWTH is worth pursuing I'd like to choose a syntax structure that allows both to coexist. "foo(int $int)" can be strongly-typed, while "foo(~int $int)" can be strongly weakly typed.

[1]: http://www.php.net/manual/en/security.magicquotes.php

Edit: forgot link

Re: Making PHP Safer

#44

Post by krapp » Sat, Feb 01, 2014, 3:28 AM UTC

wvenable wrote: post #36

ciarand wrote: post #35

Earlier quoted context omitted.

First, you're right - the core library and API does have a long way to go. Imo, we need a new major version (6) so we can break backwards compatibility for some of this craziness. But as for the annotations, the most compelling argument I've seen is to make it string (===). If you supply "123" and the method signature requires an int, it should throw an exception. If you don't want that, don't include the typehint. T…

I disagree. Strict type hinting would be ridiculous in PHP and lead to a lot of unnecessary and unsafe casting. nikic goes through all the scalar type hint options here: http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-har... Strict weak type hinting seems like the most realistic and pragmatic choice except I would add a cast to make sure the type is actually an `int` in the function.

It would be nice if you had an option, like

   function foo(weak int $i)

for weak type hinting, and

   function foo(int $i)

for strict. The arguments for weak type hinting make sense but sometimes you don't want any ambiguity.

Re: Making PHP Safer

#45

Post by wvenable » Sat, Feb 01, 2014, 3:36 AM UTC

ciarand wrote: post #43

wvenable wrote: post #36

Earlier quoted context omitted.

I disagree. Strict type hinting would be ridiculous in PHP and lead to a lot of unnecessary and unsafe casting. nikic goes through all the scalar type hint options here: http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-har... Strict weak type hinting seems like the most realistic and pragmatic choice except I would add a cast to make sure the type is actually an `int` in the function.

I've read that article, and like most of the commentators I'd like the option for strict type hinting. It's a choice I make, it's not forced on me. Having strong type hints removes any doubt from the code. I know exactly what's being passed around and what it represents, and I can be comfortable in knowing what that means. I don't need the engine to do anything magic[1] in the background. While the idea of "strong we…

Weak typing isn't magic, it's just weak typing. Weak typing for a web language makes a lot of sense.

> At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it.

I'm trying to think of an example where that wouldn't be what you want, and I can't! All the input you get from users is going to strings, most input you get from databases is going to be strings, text files are going to be strings. And since casting in PHP is so permissive, forcing strict typing is like having no typing at all.

The fact that a scalar variable has a specific binary representation is an implementation detail and PHP mostly doesn't care. The fact that a number is represented by 8 bytes two's-complement or 5 bytes ASCII really shouldn't matter. PHP plays a bit too loose with those rules but SWTH would fix a lot of that. I don't why it's necessary to force the caller to provide the correct internal representation for a value when it can be converted to the right representation without data loss or confusion. The function still gets the value it expects.

The only amendment I would add to SWTH, as I said already, is having it cast to the hinted type before the function call. With that, I can't see what argument there really is against it.

Re: Making PHP Safer

#46

Post by ciarand » Sat, Feb 01, 2014, 4:02 AM UTC

wvenable wrote: post #45

ciarand wrote: post #43

Earlier quoted context omitted.

I've read that article, and like most of the commentators I'd like the option for strict type hinting. It's a choice I make, it's not forced on me. Having strong type hints removes any doubt from the code. I know exactly what's being passed around and what it represents, and I can be comfortable in knowing what that means. I don't need the engine to do anything magic[1] in the background. While the idea of "strong we…

Weak typing isn't magic, it's just weak typing. Weak typing for a web language makes a lot of sense. > At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it. I'm trying to think of an example where that wouldn't be what you want, and I can't! All the input you get from users is going t…

>PHP plays a bit too loose with those rules

I don't think you or I disagree on this. The language does not handle strings gracefully.[1][2] The more magic casting and conversions I can remove from my codebase, the happier I'll be.

I'm sure there are some individuals that would misuse strong typing, but it would help a whole lot of people avoid some really, really dumb bugs. This isn't so much about knowing what's going on internally (binary representations), this is about being able to catch bugs early and often. It also helps in refactoring and improves the quality of linters.

But yeah, if SWTH casts if a parameter matches the definition of a type (e.g. 1.5 is not an int but 1.0 is) then SWTH is fine. There'd probably be a little bit of a performance penalty, but as long as the devs implement strict casting rules (according to Nikita's favorite proposal) then it solves my problems. As a sidenote, Nikita actually agreed to the casting change after posting that article[3].

[1]: http://phpsadness.com/sad/47 [2]: http://stackoverflow.com/a/1995196 [3]: http://www.jejik.com/articles/2012/03/a_php_type_hinting_alt...)

Re: Making PHP Safer

#47

Post by ciarand » Sat, Feb 01, 2014, 4:04 AM UTC

krapp wrote: post #44

wvenable wrote: post #36

Earlier quoted context omitted.

I disagree. Strict type hinting would be ridiculous in PHP and lead to a lot of unnecessary and unsafe casting. nikic goes through all the scalar type hint options here: http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-har... Strict weak type hinting seems like the most realistic and pragmatic choice except I would add a cast to make sure the type is actually an `int` in the function.

It would be nice if you had an option, like function foo(weak int $i) for weak type hinting, and function foo(int $i) for strict. The arguments for weak type hinting make sense but sometimes you don't want any ambiguity.

Yeah, as long as there's a way to specify a strict type then I'd be happy. Libraries and other code that's intended to be used by 3rd parties could probably benefit from weak type hinting, but internally I'd really like the confidence that comes from strict hinting.

Re: Making PHP Safer

#48

Post by wvenable » Sat, Feb 01, 2014, 4:23 AM UTC

ciarand wrote: post #46

wvenable wrote: post #45

Earlier quoted context omitted.

Weak typing isn't magic, it's just weak typing. Weak typing for a web language makes a lot of sense. > At least 70% of the bugs I encounter in the wild are due to unexpected types. SWTH doesn't fix that - if I pass in a string and it looks like a number, the function will blindly accept it. I'm trying to think of an example where that wouldn't be what you want, and I can't! All the input you get from users is going t…

>PHP plays a bit too loose with those rules I don't think you or I disagree on this. The language does not handle strings gracefully.[1][2] The more magic casting and conversions I can remove from my codebase, the happier I'll be. I'm sure there are some individuals that would misuse strong typing, but it would help a whole lot of people avoid some really, really dumb bugs. This isn't so much about knowing what's goi…

> This isn't so much about knowing what's going on internally (binary representations)

Strong typing is all about the binary representation. SWTH just cares about the values. I don't see the advantage in caring at the call site whether or not this integer is a string of numbers or a 64bit value.

But I'd probably be as ok with strong typing as you are with Strong-weak typing if PHP's casting rules weren't so permissive. If you have a function that takes an integer but you have a string, it would be logical to cast that string to an integer. But PHP casts are very permissive, and any value can be casted from a string to an int. So casting negates the benefit of type hinting.

Re: Making PHP Safer

#49

Post by kijin » Sat, Feb 01, 2014, 5:51 AM UTC

krapp wrote: post #44

wvenable wrote: post #36

Earlier quoted context omitted.

I disagree. Strict type hinting would be ridiculous in PHP and lead to a lot of unnecessary and unsafe casting. nikic goes through all the scalar type hint options here: http://nikic.github.io/2012/03/06/Scalar-type-hinting-is-har... Strict weak type hinting seems like the most realistic and pragmatic choice except I would add a cast to make sure the type is actually an `int` in the function.

It would be nice if you had an option, like function foo(weak int $i) for weak type hinting, and function foo(int $i) for strict. The arguments for weak type hinting make sense but sometimes you don't want any ambiguity.

Or something like "numeric" that allows both int and float, as well as any string that would pass the test of is_numeric(). It would be just like class inheritance: int and float would be treated as subtypes of "numeric".

Re: Making PHP Safer

#50

Post by kijin » Sat, Feb 01, 2014, 6:01 AM UTC

leeoniya wrote: post #39

kijin wrote: post #33

Type hinting for scalar types has been on and off the TODO list for PHP for a while now. PHP already has type hinting for arrays and objects, but not for scalar types like int, float, and string. It's been on the roadmap forever but nobody seems to know when the feature will actually land in a stable release. That's because type hinting for built-in scalar types is more difficult than it sounds in a dynamic language…

> if you use PDO to select a row from MySQL where the 'id' field is an integer, and you write something like ($row->id === 42), you get false because all the fields are returned as strings. this is not universally true. if you're using the mysqlnd drivers and disable prepares emulation, you get the correct types back. // Turn OFF emulated prepared statements $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);

This seriously should be the default behavior.

To anyone who is wondering what the heck the above is about, PDO/MySQL doesn't actually prepare and execute a statement when you use the prepare & execute methods. Instead, it automatically escapes all the parameters, interpolates them into the querystring, and sends the query to the database server.

This behavior is the default because, well, somebody might use an old version of MySQL (3.23 or 4.0) that doesn't support prepared statements. Never mind the vast majority of MySQL 4.1+ users who are sacrificing performance because of this outdated default.