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

What PHP 5.5 might look like

nikic.github.com

Post reply on HN
Print view View original

121–130 of 139 posts

Re: What PHP 5.5 might look like

#121

Post by pbiggar »

smsm42 wrote: post #120
pbiggar wrote: post #118

Earlier quoted context omitted.

It's been a few years (2008-2009ish), so my memory has faded a little bit. I recall a lot of discussions where no-one would listen to other people (if I recall, the scalar type checking thread from PHP 5.3 was a good example). A lot of hostility to people trying to change or improve things. Quite a lot of hostility towards users or people who complained about PHP (check out the bug tracker - very aggressive). Oh, and…

I know that there are a lot of discussions - sometimes very long and tiresome - but what you mean by "no one would listen to other people"? I.e. what would happened if things went differently and somebody would listen, say in the thread about 5.3 scalar type checking? I regularly check the bug tracker and I haven't noticed any special aggressiveness - of course, some of the volunteers may sometime be impatient, espec…

When I say "no one would listen" I mean the long and tiresome discussions. I saw people just repeating themselves, without taking on board what other people were saying. I never saw these discussions end well. There was no consensus - the discussions eventually died out without any progress.

I think there might be some Stockholm Syndrome there. The volunteers in the PHP bug tracker are dicks! Or were, it's been 3 years so things may have changed. And I'm not talking about responses to trolls, I mean to ordinary users.

I mean they disregard the feelings of the other people in the community, not their code. I'm not really talking about how dysfunctional the coding practices were, I mean the actual community dynamics. It felt a lot like trolls feeding trolls.

Re: What PHP 5.5 might look like

#122

Post by smsm42 »

frosas wrote: post #57
Smerity wrote: post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

I agree keyword arguments are a better solution (but probably harder to implement). Right now this is how I do this: function salute($user, array $options = null) { $options = (array) $options + array('shout' => false); $salutation = "Hi $user!"; if ($options['shout']) $salutation = strtoupper($salutation); return $salutation; }

It is significantly harder to implement, especially if you think about what happens with existing functions, especially internal ones.

Re: What PHP 5.5 might look like

#123

Post by ricardobeat »

fleitz wrote: post #107
Smerity wrote: post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

array_column looks like a half-assed version of map. Looks like PHP hasn't changed a bit. Functions that do half of what their supposed to do and have odd names that depart wildly from industry standard language.

to be fair he did mention array_pluck, but the odds are for the most awkward name.

Re: What PHP 5.5 might look like

#124

Post by comex »

masklinn wrote: post #86
DomBlack wrote: post #78

Earlier quoted context omitted.

Every hashing algorithm allows it, even bcrypt. Very simple example; md5($salt.$pepper.$clearText); The problem with this API is that if you pass in the "salt" as $salt.$pepper then the output hash also contains the pepper. The whole point of a pepper is to keep a second salt out of the database. The user salt would be in the database, but the pepper should only be in the application code. If your database is stolen,…

> Every hashing algorithm allows it, even bcrypt. That is not the meaning I intended in my usage of the word "support", but if you equate "support" and "is compatible with", then this API also "supports" peppers, just as much as bcrypt does. > md5($salt.$pepper.$clearText) How cute, not just md5 but length-extension vulnerable MD5. I'd recommend not using that scheme for MACs (and more generally not using md5 directl…

A length extension attack is fairly irrelevant for password storage...

Re: What PHP 5.5 might look like

#125

Post by gurkendoktor »

cpeterso wrote: post #108
gurkendoktor wrote: post #79

> PHP 5.5 will no longer support Windows XP and 2003. Those systems are around a decade old, so PHP is pulling the plug on them. Given the recent threads about planned obsolescence (Apple) and OS fragmentation (Android) I'm curious what is missing from XP/2003 that is part of Vista+. Are there still exciting things happening in the world of OS APIs that are relevant for server software? Or does this just mean that no…

I believe Visual Studio 2010 and 2012 generate code that imports MSVCRT functions that are not available on Windows 2000 or XP: https://connect.microsoft.com/VisualStudio/feedback/details/... https://connect.microsoft.com/VisualStudio/feedback/details/...

The VS2010 MSVCRT still runs on Windows XP SP2+ as mentioned in your second link.

The VS2012 MSVCRT will not run on XP initially, but a post-RTM patch to bring XP support back was mentioned on the VS blog[1]. So that would only prevent XP support between the VS2012 release and the post-RTM patch, and only if the PHP team upgraded at the first chance.

[1]: http://blogs.msdn.com/b/visualstudio/archive/2012/05/18/a-lo...

Re: What PHP 5.5 might look like

#126

Post by rmccue »

Smerity wrote: post #6

The introduction of list comprehensions is nice and should replace numerous functions. For example, I'm not sure why they're adding the array_column function into PHP 5.5 at the same time as list comprehensions as: $names = array_column($users, 'name'); // is the same as $names = [foreach ($users as $user) yield $user['name']]; The only possible reason would be due to a significant speed difference, but I'd suggest i…

Agreed on keyword args. I maintain Requests for PHP [1] which has a very similar API to Python Requests, and at the moment, you have to use an array as the options parameter.

    $options = ['timeout' => 0.5];
    $r = Requests::get('https://api.github.com/', $headers, $data, $options);
[1]: http://requests.ryanmccue.info/

Re: What PHP 5.5 might look like

#127

Post by smsm42 »

pbiggar wrote: post #121
smsm42 wrote: post #120

Earlier quoted context omitted.

I know that there are a lot of discussions - sometimes very long and tiresome - but what you mean by "no one would listen to other people"? I.e. what would happened if things went differently and somebody would listen, say in the thread about 5.3 scalar type checking? I regularly check the bug tracker and I haven't noticed any special aggressiveness - of course, some of the volunteers may sometime be impatient, espec…

When I say "no one would listen" I mean the long and tiresome discussions. I saw people just repeating themselves, without taking on board what other people were saying. I never saw these discussions end well. There was no consensus - the discussions eventually died out without any progress. I think there might be some Stockholm Syndrome there. The volunteers in the PHP bug tracker are dicks! Or were, it's been 3 yea…

There indeed was no consensus on the topic of strict typing and on some other topics - but it's only natural, people have different opinions and sometimes there's just no agreement between them. Especially if you are advocating wide regard for all people in the community, you have to accept that sometimes there would be no way to reach a decision that is agreeable to everyone. In the strict typing case that is what happened, there was no approach that was satisfactory to all, so the decision was to remain with the status quo. I don't think this makes PHP internals somehow hostile or "poisonous" - disagreement is a natural part of the process in such a diverse community, and in case there's no agreement on a new feature the natural way is to remain with the status quo.

Re: What PHP 5.5 might look like

#128

Post by smsm42 »

debacle wrote: post #22
Spoom wrote: post #15

Earlier quoted context omitted.

I'm curious: Why do you think empty() should be deprecated? Do you think the same of isset?

http://www.zachstronaut.com/posts/2009/02/09/careful-with-ph... http://stackoverflow.com/questions/410002/fixing-the-php-emp... The behavior of empty is unreliable. isset is not ambiguous.

What you mean "unreliable"? It is completely reliable and described in the documentation. It doesn't fit some use cases, in these cases you could use other facilities provided by the language, PHP can not have separate language construct for every use case.

Re: What PHP 5.5 might look like

#129

Post by smsm42 »

Sander_Marechal wrote: post #92

The proposals look great! But I'm missing one thing: Less fatal errors, or a better way to catch them. Especially for the case of calling a method on a null value. E.g. $foo->getBar()->getBaz() If getBar() return NULL for some reason, you get a fatal error which you cannot catch and handle without reverting to uglu hacks with a shutdown function. My personal preference would be to have that statement return NULL and…

Don't return null from that function. Return NullObject which has __call() { return $this; } - then you could chain as many such calls as you want and they'd be OK with nulls. Then you could check for NullObject as easily as you could check for null - if($result instanceof NullObject) etc.

Re: What PHP 5.5 might look like

#130

Post by pbiggar »

smsm42 wrote: post #127
pbiggar wrote: post #121

Earlier quoted context omitted.

When I say "no one would listen" I mean the long and tiresome discussions. I saw people just repeating themselves, without taking on board what other people were saying. I never saw these discussions end well. There was no consensus - the discussions eventually died out without any progress. I think there might be some Stockholm Syndrome there. The volunteers in the PHP bug tracker are dicks! Or were, it's been 3 yea…

There indeed was no consensus on the topic of strict typing and on some other topics - but it's only natural, people have different opinions and sometimes there's just no agreement between them. Especially if you are advocating wide regard for all people in the community, you have to accept that sometimes there would be no way to reach a decision that is agreeable to everyone. In the strict typing case that is what h…

My point is not that there should be consensus. My point is how the discussion went (and many similar discussions, not just one). Poison comes from how community members treat each other, not whether or not they can agree on something.

I've spent major time in 3 open source projects, gcc, Mozilla and PHP. All of them suffered from similar disagreement, from old code, from old decisions they need to move away from. The difference was that Mozilla and gcc manage to do it without being poisonous.

Post reply on HN