[Slice]

Caught this blog post on twitter and thought there were some interesting ideas being talked about.

Quote

But be sure to understand this: PHP 5.5 is in an early development stage, so nobody knows how the end result will look like. All I am talking about here are proposals. I’m pretty sure that not all of the things listed below will go into PHP 5.5, or at least not in their current form.

So, don’t get too excited about this

The list of new features / proposals is rather large and not sorted by significance. So if you don’t want to read through all of it, here are the four features I personally am most excited about:

A simple API for password hashing
Scalar typehinting
Getters and setters
Generators

The idea of an API for password hashing seems pretty cool, especially as an easier method to teach when talking about database security.

So is there anything not on there that you would like to see in the next release? Or any proposed ideas you don't care for?

[Dormilich]

Slice, on 13 July 2012 - 12:36 PM, said:

The idea of an API for password hashing seems pretty cool, especially as an easier method to teach when talking about database security.

It might not have been necessary, if (new) developers would actually learn about security in the first place.


I never thought that scalar type hinting had such issues in its implementation, but I would really like to see them implemented.

[RudiVisser]

Parameter skipping ew ew ew ew ew ew ew ew ew ew ew ew

Named parameters. Get them!

[AdaHacker]

RudiVisser, on 13 July 2012 - 08:54 AM, said:

Parameter skipping ew ew ew ew ew ew ew ew ew ew ew ew

Heh, parameter skipping. That's classic. It'll be just like writing in VB6 all over again. Way to step into 1996, PHP team!

Also, the scalar type hinting semantics he describes are stupid. In my book, the only correct choice is strict enforcement - if I ask for an int, I should get a freakin' int. If I didn't care about the actual data type, then why did I need the hint in the first place? It's like they're trying to use type-checking as a form of cheap parameter validation rather than type enforcement. They need to make up their minds what this feature is for.

And I did read the linked article on why scalar type hinting is hard. My take-away from it was that this guy is just full of crap. Scalar type hinting is not hard, the problem is just that the PHP devs can't get their priorities straight. Just consider his quote in the discussion of the strict type hinting option:

Quote

One of PHP’s greatest strengths is being a weakly typed language and this proposal would turn it into a strictly typed one. This goes against the PHP philosophy and also differs from how pretty much everything else works in PHP.

Does he not see the irony that having type hinting at all goes against this "philosophy"? Why is it suddenly a violation of the language's principles to enforce a difference between two types of primitives, but not between two types of objects? This just reinforces my previous belief that the PHP devs have no sense of leadership or direction for the language. It's like they're just tacking on new features, trying to be all things to all people, and that just doesn't work.

[RudiVisser]

I read that piece aswell and found it quite amusing. Completely agree that when I'm type-hinting it should be considered as more like type-needed or type-expected, if it's not that type (not utilising PHP's magic auto conversion shite) then I don't want it at all and it certainly should be fatal. I don't even want these people to use my methods who are going to be calling it incorrect.

What scares me most is that a proposal that is based wholly on utilising PHP's magic type conversion to the max it seems, is the one that he listed as 'Proposed'. That scares me, this needs to be strong or it shouldn't be there at all.

AdaHacker, on 13 July 2012 - 03:54 PM, said:

It's like they're just tacking on new features, trying to be all things to all people, and that just doesn't work.

Well that's all they've done for years, tried to cater for everyone from beginners to advanced. Trying to keep the learning curve to the absolute minimum of "hey you can have a HTML page and put <?php echo 1+1 ?> in there and holy shit you've got a calculator" type thing, whilst also trying to cater for those like us that actually seriously want to take the language seriously.

I'm not a PHP basher in the whole-hearted sense, I use it every day, it is (was) the primary focus of my career for the past 6 years and I'm all for it improving, but since I've been working with C# (specifically ASP.NET MVC) on a more daily basis it just makes me realise that PHP really needs to step up it's game to cater for and attract much more professional developers. Most people still treat PHP as a toy language and I can understand it.

IMO - It needs to decide whether it wants to be a template language with OOP bolted on, or a language that can be taken seriously.

I'm sure many people don't agree with my views but on the flip side really hope that they do. There are very few people that praise the current development effort by the PHP Core team, why the hell don't they wake up and fix that.

EDIT: It's the most basic of things like this bug I filed that keeps me from taking it seriously even more. Their path support must be implemented in a completely arbitrary fashion per extension or even method. I say method, because is_writable fails on a UNC path, too, whereas I can quite happily call file_put_contents with the same path and have it work just fine.

This post has been edited by RudiVisser: 13 July 2012 - 08:20 AM

[Atli]

AdaHacker, on 13 July 2012 - 02:54 PM, said:

Also, the scalar type hinting semantics he describes are stupid. In my book, the only correct choice is strict enforcement - if I ask for an int, I should get a freakin' int.

In the proposal the blog post Slice posted references, that is exactly what you would get. PHP would cast the input value to the type you requested, or fail if that isn't possible.

This, in my opinion, is the only way that makes sense. PHP is not strongly typed, so bugging out every time a value that is not of the hinted type is passed is not an option. If PHP's normal type-juggling can cast the input value into the requested type without losing precision, then that is what it should do. - All that matters, really, is that the value you get into the function is of the type you hinted at.

AdaHacker, on 13 July 2012 - 02:54 PM, said:

Why is it suddenly a violation of the language's principles to enforce a difference between two types of primitives, but not between two types of objects?

Because PHP has been juggling primitive types in the background for as long as it has existed, but it has never done the same for objects. Nobody is expecting PHP to magically cast their "Foo" object to a "Bar" object on the fly, but people do expect PHP to convert their "1.0" string to an 1 integer without them having to explicitly tell it to do so.

For strongly typed languages it makes sense to enforce primitive type differences, and I get why you'd prefer that (I do prefer that, actually), but that is not a reasonable expectation for PHP. PHP is not strongly typed, and it juggles primitive types automatically. It's just how it works, and how it has always worked. You can't expect that to suddenly change just so this one feature can mimic how strongly typed languages implement it.

[AdaHacker]

Atli, on 14 July 2012 - 12:43 AM, said:

In the proposal the blog post Slice posted references, that is exactly what you would get.

Well...sort of. What the proposal actually says is that you'd get the type you asked for without data loss, except when you wouldn't. Instead of just making it clear and simple, the RFC includes a few exceptions that sort of do what you might expect, depending on who you are. That's part of the problem.

Quote

Because PHP has been juggling primitive types in the background for as long as it has existed, but it has never done the same for objects.

That's because you can't do the same for objects. But if you truly embrace dynamic typing, you don't need to. You can simply use duck typing.

But that just brings me back to my original point. If you expect PHP to do type juggling on your parameters, then why are you specifying a type on them in the first place? Half the point of type juggling is that you don't need to worry about the explicit type. So why does this feature even need to exist? Isn't the whole point of it to do things differently from what you'd traditionally expect?

Atli, on 14 July 2012 - 12:43 AM, said:

PHP is not strongly typed, and it juggles primitive types automatically. It's just how it works, and how it has always worked. You can't expect that to suddenly change just so this one feature can mimic how strongly typed languages implement it.

That's a fair point. So let's look at similar dynamic languages and see what we can learn from the way they implement explicit type specifications on parameters. Anyone have some examples? I'm sure there must be a few others that implement them, but off the top of my head I can't think of any. However, I know loads of statically typed languages that do.

My point is that appealing to the loose, dynamic nature of PHP just doesn't make sense here. We're talking about a feature that is inherently about making typing more strict. It's a feature most people have only ever seen in statically typed languages. Therefore, if you're going to implement it, implement it as you would in a statically typed language, because that's what people will expect. To me, invoking the loose and dynamic nature of the language undermines the entire case for implementing this feature at all.