Hi!
You had less complex patch posted on #35050 bug report for the last four
years.
That patch, unfortunately, is not correct since it assumes every
function using tolower wants ASCII tolower. This makes, for example,
substr_compare() ignore locale, and probably a bunch of other functions.
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
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
hi,
On Thu, Jul 12, 2012 at 7:17 AM, Tomas Kuliavas
to...@users.sourceforge.net 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.
hi Ziad,
On Thu, Jul 12, 2012 at 9:28 AM, Ziad Jammal z...@eljammal.com 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
On Thu, Jul 12, 2012 at 1:49 AM, Johannes Schlüter
johan...@schlueters.de 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
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
What about replacing the existing array with array_slice?
David
On 12/07/2012, at 9:43 PM, Jille Timmermans ji...@quis.cx 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
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
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
prevent
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
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) {
On 2012-07-12, Sara Golemon poll...@php.net wrote:
--e89a8f235453d7a80104c4975c55
On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara ircmax...@gmail.comwrote:
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
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
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
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 like
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 more weird
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 of
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 make the
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 patch
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 boilerplate type
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
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 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 disagree
2012/7/12 Anthony Ferrara ircmax...@gmail.com:
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
On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach alex.aulb...@gmail.com 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
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 these
Em Thu, 12 Jul 2012 18:30:43 +0200, Stas Malyshev smalys...@sugarcrm.com
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,
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:
2012/7/12 Nikita Popov nikita@gmail.com:
On Thu, Jul 12, 2012 at 7:24 PM, Alex Aulbach alex.aulb...@gmail.com wrote:
1. The resulting string should have a version information. For example
the first char. the example hash will look like
hi Anthony!
On Mon, Jul 9, 2012 at 5:19 PM, Anthony Ferrara ircmax...@gmail.com 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
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
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 would
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_BCRYPT,
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
2012/7/12 Anthony Ferrara ircmax...@gmail.com:
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
On 13/07/12 01:04, Matthew Weier O'Phinney wrote:
On 2012-07-12, Sara Golemon poll...@php.net wrote:
--e89a8f235453d7a80104c4975c55
On Wed, Jul 11, 2012 at 5:39 PM, Anthony Ferrara ircmax...@gmail.comwrote:
One thing to keep in mind when doing this is to think about consistency.
I think
37 matches
Mail list logo
