On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
> On 2012-07-12, Sara Golemon wrote:
>> --e89a8f235453d7a80104c4975c55
>> On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara wrote:
>>> One thing to keep in mind when doing this is to think about consistency.
>>> I think that's a huge point not to be
2012/7/12 Anthony Ferrara :
> That's what $2y$ is for. It's a standard crypt() prefix algorithm
> identifier. For example you can use $1$ for md5, $5$ for sha256 and $6$ for
> sha512 algorithms. In the future, if new algorithms are added, it would be
> added as a new prefix for crypt()...
Ya, didn
Alex,
First off, thanks for such a thorough reply!!! Comments are inline.
1. The resulting string should have a version information. For example
> the first char. the example hash will look like
> "1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi",
> instead of "$2y$07$usesomesillys
Stas,
> https://wiki.php.net/rfc/password_hash
>
> Looks good. The only question I have is for password_make_salt() - do we
> need the user to specify length? I think length is defined by the
> algorithm in the most cases. Maybe convert it to password_make_salt(int
> $salt_type = PASSWORD_SALT_BC
Pierre,
> I've added a pair of new functions to the RFC and implementation:
> >
> > password_needs_rehash($hash, $algo, array $options = array())
>
> Not totally convinced about that one.
I'm not either. That's why I added the discussion point around it. I can
see it going either way.
> I woul
Hi!
> https://wiki.php.net/rfc/password_hash
Looks good. The only question I have is for password_make_salt() - do we
need the user to specify length? I think length is defined by the
algorithm in the most cases. Maybe convert it to password_make_salt(int
$salt_type = PASSWORD_SALT_BCRYPT, int $
hi Anthony!
On Mon, Jul 9, 2012 at 5:19 PM, Anthony Ferrara wrote:
> I've added a pair of new functions to the RFC and implementation:
>
> password_needs_rehash($hash, $algo, array $options = array())
Not totally convinced about that one. I would prefer a password_rehash
instead, then a simple c
2012/7/12 Nikita Popov :
> On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach wrote:
>> 1. The resulting string should have a version information. For example
>> the first char. the example hash will look like
>> "1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi",
>> instead of "$2y$07$use
Would it be worth while adding a new type hint that checks for this
condition? I'd propose Iterable:
I'd love to see something like this added to core.
--
Christer Edvartsen
http://twitter.com/#!/cogocogo
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://
Em Thu, 12 Jul 2012 18:30:43 +0200, Stas Malyshev
escreveu:
Would it be worth while adding a new type hint that checks for this
condition? I'd propose Iterable:
I see more and more multiplication of weird ad-hoc type checks. First we
had "callable", now "traversable", then we invent more an
Hi!
>
> I don't think you need boilerplate for every call. Either you create
> what you're going to pass to said function call, or you type-hint it
> properly on that method. The onus is on the creator of the variable, not
> the consumer.
>
> Additionally, we could add other is_* functions for
On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach wrote:
> 1. The resulting string should have a version information. For example
> the first char. the example hash will look like
> "1$2y$07$usesomesillystringfore2uDLvp1Ii2e./U9C8sBjqp8I90dH6hi",
> instead of "$2y$07$usesomesillystringfore2uDLvp1Ii2e.
2012/7/12 Anthony Ferrara :
> Hello all,
>
> Since the discussion has died down around the concept, I have updated the
> RFC and moved it into Proposed (under discussion) status.
>
> I have updated the RFC to include a section on discussion points containing
> points that I know were raised but I f
On 07/12/2012 10:19 AM, Stas Malyshev wrote:
> Hi!
>
>> This gives quite a bit more info since we now know that it was an
>> argument and specifically which argument it was, what its type was and
>> what it should have been vs. having a fatal from somewhere deep in the
>> function itself. So I dis
Hi!
> This gives quite a bit more info since we now know that it was an
> argument and specifically which argument it was, what its type was and
> what it should have been vs. having a fatal from somewhere deep in the
> function itself. So I disagree with you on it not making life easier for
> the
On 07/12/2012 12:28 AM, Ziad Jammal wrote:
Deal all phpiers,
It took me a while before I hit the send key.
I have been a php developer for some time and I got certified beginning of this
year.
I have always wanted to start contributing to php and zend framework, but I am unable to
find the r
On 07/12/2012 09:46 AM, Stas Malyshev wrote:
> Hi!
>
>> For non-interchangeable types it is already strict by definition. I
>> don't see a problem with type hints that make life easier on both the
>> caller (by generating better error messages) and the callee (by having
>> to write less boilerplat
On 12/07/12 17:30, Johannes Schlüter wrote:
> Hi,
>
> On Thu, 2012-07-12 at 17:09 +0200, Jille Timmermans wrote:
>> An implementation is quite simple:
>> https://github.com/Jille/php-src/commit/31a1aa384c29487e077ccf3fd067eca188cf1201
> Without looking at the functional change itself a comment: The
Stas,
> For non-interchangeable types it is already strict by definition. I
> > don't see a problem with type hints that make life easier on both the
> > caller (by generating better error messages) and the callee (by having
> > to write less boilerplate type verification code).
>
> It doesn't mak
Hi!
> For non-interchangeable types it is already strict by definition. I
> don't see a problem with type hints that make life easier on both the
> caller (by generating better error messages) and the callee (by having
> to write less boilerplate type verification code).
It doesn't make the life
On 07/12/2012 09:30 AM, Stas Malyshev wrote:
> Hi!
>
>> Would it be worth while adding a new type hint that checks for this
>> condition? I'd propose Iterable:
>
> I see more and more multiplication of weird ad-hoc type checks. First we
> had "callable", now "traversable", then we invent more and
Hi!
> Would it be worth while adding a new type hint that checks for this
> condition? I'd propose Iterable:
I see more and more multiplication of weird ad-hoc type checks. First we
had "callable", now "traversable", then we invent more and more weird
functional types with complex logic. I don't
Hi,
On Thu, 2012-07-12 at 17:09 +0200, Jille Timmermans wrote:
> An implementation is quite simple:
> https://github.com/Jille/php-src/commit/31a1aa384c29487e077ccf3fd067eca188cf1201
Without looking at the functional change itself a comment: The patch in
this form can not be applied to 5.4 as php
Hello,
When you create process with proc_open() (or popen()) you'll get a
process-resource. The destructor of this resource calls waitpid() (or
it's Windows-equivalent) and waits for the childprocess to die.
I think it is very counter-intuïtive that when you derefence the
resource it will wa
On 2012-07-12, Sara Golemon wrote:
> --e89a8f235453d7a80104c4975c55
> On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara wrote:
> > One thing to keep in mind when doing this is to think about consistency.
> > >
> >
> > I think that's a huge point not to be taken lightly. For that reason, I
> > think
Hello all,
At present, there's now way to type hint over a generic structure that it
iteratable using foreach(). You can accept arrays using the array hint, and
objects using traversable, but you cannot hint both. This yields code that
wants to accept that to look like this:
function foo($a) {
Op 12-07-12 15:18, Johannes Schlüter schreef:
On Thu, 2012-07-12 at 13:43 +0200, Jille Timmermans wrote:
Hello,
array_shift() currently reindexes the array after shifting one element.
The reindexing has quite some impact on it's performance. I would like
to suggest an extra parameter to array_s
On Thu, 2012-07-12 at 13:43 +0200, Jille Timmermans wrote:
> Hello,
>
> array_shift() currently reindexes the array after shifting one element.
> The reindexing has quite some impact on it's performance. I would like
> to suggest an extra parameter to array_shift() which can be used to
> preven
It seems 7-8 times slower than array_shift() and that is even without a
way to fetch the first value.
I tried
`$array = array_slice($array, 1)`
and
`$array = array_slice($array, 1, NULL, true);`
-- Jille
Op 12-07-12 14:39, David Muir schreef:
What about replacing the existing array with a
What about replacing the existing array with array_slice?
David
On 12/07/2012, at 9:43 PM, Jille Timmermans wrote:
> Hello,
>
> array_shift() currently reindexes the array after shifting one element. The
> reindexing has quite some impact on it's performance. I would like to suggest
> an ext
Hello,
array_shift() currently reindexes the array after shifting one element.
The reindexing has quite some impact on it's performance. I would like
to suggest an extra parameter to array_shift() which can be used to
prevent reindexing.
From a few quick (and sloppy!) tests I get these resul
On Thu, Jul 12, 2012 at 1:49 AM, Johannes Schlüter
wrote:
> One thing to keep in mind when doing this is to think about consistency.
> Right there's quite a distinction. Things either take an array or a
> Traversable object. We should think about not creating a mess when some
> functions, especial
hi Ziad,
On Thu, Jul 12, 2012 at 9:28 AM, Ziad Jammal wrote:
> Deal all phpiers,
>
> It took me a while before I hit the send key.
> I have been a php developer for some time and I got certified beginning of
> this year.
> I have always wanted to start contributing to php and zend framework, but
hi,
On Thu, Jul 12, 2012 at 7:17 AM, Tomas Kuliavas
wrote:
> It is not about issues with functions. It is about PHP interpreter
> operating under assumption that locale sensitive strtolower and
> strtoupper follow basic US English letter case rules in a-zA-Z range.
> That's huge mistake for code
Hi there!
Please note that this is the "internals" mailing list, and developing PHP
internals is mainly a question of C programming language.
If you want to get started with some framework you've been using, I can
only suggest you to get in touch with the existing core developers
responsible for
Deal all phpiers,
It took me a while before I hit the send key.
I have been a php developer for some time and I got certified beginning of this
year.
I have always wanted to start contributing to php and zend framework, but I am
unable to find the right docs, examples, and the "how".
I know it
36 matches
Mail list logo
