61–70 of 139 posts
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.
I think a standard password hash API is a good thing (there was a proposal for such a thing for Python recently on -ideas, though it was essentially rejected in favor of recommending/using passlib), but I'm wary of having default cost factors, that seems unwise: what are the defaults, how are they decided to be ok, and more importantly in what context are they updated over time (and based on what data)?
The problem with it in it's current form is it does not allow for an application pepper. Also I'd prefer it to support scrypt as well as bcrypt.
Considering:
* no password hash algorithm I know of supports peppers
* that the API allows providing a custom salt
I don't see any issue with the API. If the cryptographic worth of peppers is ever demonstrated and a password hash is built to use peppers, the pepper can be provided as an option to that hash algorithm as the salt and cost already are in the proposed API.
Pretty exciting, though empty() should be deprecated, not improved upon. The bit about getting the fully qualified class name is important, but it still prevents you from doing something like: function builder_factory( $var ) { $class = $some_array[ $var ]; return new $class(); } So you have to write a ton of boilerplate for something that used to be easy without namespaces, or write namespace traversal into your PHP…
There's nothing functional to skipping parameters, as far as I know. None of the functional languages I've used supports such a concept, nor would it make sense in most of them.
The explanation, a bit further down in the eRFC is that the function password_hash doesn't actually return a password hash, but a string including the algorithm and options used, the salt and the hash itself.
From the RFC:
> It's important to note that the output of crypt() (and hence password_hash()) contains all the information that will be needed to verify the hash later. Therefore, if the default hashing algorithm changes, or the user changes their algorithm, old hashed passwords would still continue to function and will be validated properly.
These sound like useful improvements, especially the new getter/setter syntax and scalar type hinting. However, what I'd really like to see in next PHP would be the Composer dependency manager bundled in, a bit like Node.js nowadays ships with NPM. This has really brought a new world of cross-project code sharing into PHP: http://packagist.org/ I wrote a blog post on why this is important for improving the state of P…
I think composer is a bit too young to introduce into the language. Perhaps it will prove out to be robust, but I'd wait a little while before introducing it to core...
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…
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…
IMO This is a problem and bad design, because instead of default arguments you can use properties for optional arguments.
[1] oh look, I'm still mentioned in the RFC :) - https://wiki.php.net/rfc/scalar_type_hinting_with_cast
Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?
PHP enforces a lot of things in the parser (as opposed to making bytecode and having a simple type checker). Instead of having a general "expression" type which can be dereferenced, they have different rules for scalars, strings, variables, function calls, etc. For a long time, you couldn't dereference the result of a function call, because the parser didn't allow it, so this is probably the same.
Regarding the "constant dereferencing" proposal, how do you even make a language parser that can't apply array operations to literals in the first place? I'm trying very hard not to bash on PHP here, and this is a completely honest question. I can't figure out how you'd even go about breaking that if you wanted to. Anyone know the background there?
One reason it is like that has to do with string interpolation. PHP interpolates $x[0] inside double quotes, but does not (and probably should not) interpolate [0][0]. I am not saying this is a good solution, but hopefully that answers "how is that even possible?" question.