Hello!
The PHP development team announces the immediate availability of PHP
5.4.39. Six security-related bugs were fixed in this release, including
CVE-2015-0231, CVE-2015-2305 and CVE-2015-2331. All PHP 5.4
users are encouraged to upgrade to this version.
For source downloads of PHP 5.4.39
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
This proposes adding one function: `preg_replace_callback_array()` that
is
Hi!
We're doing some performance work in WinCache, and we're finding that
some frameworks are...uh...enthusiastically using file_exists(),
is_file() and is_dir() functions on files/directories that don't
exist. Every. Single. Pageload.
Does the PHP stat cache include negative cache
On Wed, Mar 18, 2015 at 05:57:22PM +0900, Yasuo Ohgaki wrote:
I would like to fix this bug transparently. i.e. User cannot detect already
destroyed
session that is accessible.
The method is:
1. Add __SESSION_TTL__, which has TTL timestamp, to $_SESSION hash before
serialization.
2. If
2015.03.19. 18:40 ezt írta (Dan Ackroyd dan...@basereality.com):
On 19 March 2015 at 17:14, François Laupretre franc...@php.net wrote:
As you may have noticed if you had a look at the RFC or twitter, I have
decided to follow people's suggestion.
Please note that the switch from E_DEPRECATED
On 20 March 2015 at 10:38, Leigh lei...@gmail.com wrote:
I've tried implementing python style slice on both strings and arrays in
the past (I don't seem to have an existing branch with it in any more
though it seems). The biggest problems I hit were regarding the syntax, the
functionality
I want to mention
http://php.net/manual/en/opcache.configuration.php#ini.opcache.enable-file-override
option, that can cache positive checks information between subsequent
requests.
Thanks!
2015-03-20 9:13 GMT+03:00 Stanislav Malyshev smalys...@gmail.com:
Hi!
We're doing some performance
On 20 March 2015 01:28:53 GMT, Alex Bowers bowersb...@gmail.com wrote:
I'm not sure what you mean by something that happens nowhere else PHP
has
syntax for all sorts of things, using all sorts of symbols. Your own
suggestion uses the : symbol in a place where it currently can't
exist.
What I
I've tried implementing python style slice on both strings and arrays in
the past (I don't seem to have an existing branch with it in any more
though it seems). The biggest problems I hit were regarding the syntax, the
functionality itself worked.
If you've got a link to your messaging
That said, I'm a little older and wiser than I was then, I'd still be
interested in looking at this. I'll try and come up with _something_ that
works over the weekend.
I started on the code last night, but didn't get very far. I got it to
match the T_COLON, but no logic or parsing has been
On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
This proposes
The @ symbol in my examples is not a special marker that is meaningful on
its own; the parser wouldn't even see it as a separate token. The syntax
for key access is $array[$key], the syntax for positional access would be
$array[@$position]; chosen to look similar, but one is not a special
hi,
On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon pjsturg...@gmail.com wrote:
While you can easily question the value or motives of Anthony's post
about voting irregularities, some simple improvements can be made
which are uncontroversial. I consider this a low hanging fruit, like
Hi!
This may be not so easy to implement - imagine passing $array[*1:4] by
reference.
This would be the same as doing
$array[array_keys($old_array)[1]] = $new_array[0];
$array[array_keys($old_array)[2]] = $new_array[1];
$array[array_keys($old_array)[3]] = $new_array[2];
On 20 March 2015 at 23:03, Stanislav Malyshev smalys...@gmail.com wrote:
$array[*1:4] by reference -
what is actually passed?
Implementation is not something I have looked into for this yet, so I am
unsure how this would be possible; but by passing $array[*1:4], you'd be
passing an extracted
Developing the PHP runtime
Maintaining an official, bundled PHP extension
Maintaining the documentation
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye pierre@gmail.com wrote:
hi,
On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon pjsturg...@gmail.com
wrote:
While you can easily question the value or motives of Anthony's post
about voting irregularities, some simple improvements can be made
Hi!
Implementation is not something I have looked into for this yet, so I am
unsure how this would be possible; but by passing $array[*1:4], you'd be
passing an extracted array which is a reference to the original array.
Such that changing the sub array can change the parent array.
Exactly.
Alex Bowers wrote on 20/03/2015 13:10:
$array['x':'z'] = []; // Remove all elements with keys between 'x'
and 'z', inclusive
I believe i mentioned in the past about strings not being allowed for
ranges, since there is no real way to check this (and this appears to
be by key not by
Hi Rowan,
On Fri, 2015-03-20, at 13:17, Rowan Collins wrote:
I personally like the idea of string offsets having similar but slightly
different syntax from array offsets, to make clear which you're using. I
use {} instead of [] for that reason, but at the moment the syntaxes are
On Mar 20, 2015 12:33 PM, Alex Bowers bowersb...@gmail.com wrote:
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist, or
should it be a parse error?
I'd say
It's an alternative syntax
Learn something new every day.
I guess this RFC will need to support both then for consistency reasons; so
it will be down to the end user to determine how they want to separate them
if they choose to. But I don't think we should only match {} for strings
and [] for
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist, or
should it be a parse error?
Hey:
On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams a...@phcomp.co.uk wrote:
On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
Hi internals,
Hi internals,
The RFC to add a user-land function for an
On Mar 20, 2015 11:40 AM, Alex Bowers bowersb...@gmail.com wrote:
I've tried implementing python style slice on both strings and arrays in
the past (I don't seem to have an existing branch with it in any more
though it seems). The biggest problems I hit were regarding the syntax,
the
Alex Bowers wrote on 20/03/2015 13:09:
On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com
mailto:rowan.coll...@gmail.com wrote:
$version{4:} = '7!';
I'm sure this is a slight oversight on your end, but just to check.
The change of using {} instead of [] is not because
On 20 March 2015 at 13:04, Rowan Collins rowan.coll...@gmail.com wrote:
$version{4:} = '7!';
I'm sure this is a slight oversight on your end, but just to check. The
change of using {} instead of [] is not because its a string, and is just a
typo / example correct?
Alex Bowers wrote on 20/03/2015 11:38:
The @ symbol in my examples is not a special marker that is
meaningful on its own; the parser wouldn't even see it as a
separate token. The syntax for key access is $array[$key], the
syntax for positional access would be $array[@$position];
Good day,
My Wiki username is: alexbowers
I have an RFC currently under gauge within the thread (link:
https://marc.info/?l=php-internalsm=142679821024794w=2 )
Which seems to be getting some positive reviews, and so I would like to
write an official RFC to be placed into discussion.
Thanks,
Alex Bowers wrote on 20/03/2015 12:32:
We also need to consider then the possibility of setting data by position.
What should $array[@1:3] = [1,2,3] do?
Should it overwrite the values there, and append any that don't exist,
or should it be a parse error?
Good catch. I guess it could
$array['x':'z'] = []; // Remove all elements with keys between 'x' and
'z', inclusive
I believe i mentioned in the past about strings not being allowed for
ranges, since there is no real way to check this (and this appears to be by
key not by index) which should be a separate RFC thread,
Okay,
Still not sure how we can implement a range of strings. But since thats for
a different feature, I'll leave that issue for now.
In the list you provided, all of the ones for positional slicing will
definitely be implemented.
Question: What would be the best name for this feature? I do
On Mar 20, 2015 2:59 PM, Alex Bowers bowersb...@gmail.com wrote:
So $dictionary['elephant':'snake'] returns all elements with keys which
sort lexically between 'elephant' and 'snake', regardless of whether the
array is sorted.
Makes sense to me.
Alternatively, a key-based slice could
So $dictionary['elephant':'snake'] returns all elements with keys which
sort lexically between 'elephant' and 'snake', regardless of whether the
array is sorted.
Makes sense to me.
Alternatively, a key-based slice could look up the position in the array of
the two keys, and then perform a
Am 20.03.2015 um 09:03 schrieb Wei Dai:
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
https://wiki.php.net/rfc/preg_replace_callback_array
This proposes adding one function:
Alex Bowers wrote on 20/03/2015 13:40:
Still not sure how we can implement a range of strings. But since
thats for a different feature, I'll leave that issue for now.
I can't resist a quick answer: if you can define a key-based slice at
all, you can define it for both integer and string keys.
I know that many people talked about this over and over.
Why it’s not possible to change the old PHP API ?
The answer is always because it will make HUGE BC breaks
I’ve seen this wonderful idea about scalar objects authored by nikic
github https://github.com/nikic/scalar_objects.
This
On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote:
On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai zxcvda...@gmail.com wrote:
Hi internals,
Hi internals,
The RFC to add a user-land function for an easy-to-use and reliable
preg_replace_callback_array() in PHP is up for discussion:
If your branch is available on github let me know, more than happy work on
it with you.
I'll publish it tonight (GMT), I'm at work at the moment.
Thanks!
Hello!
The PHP development team announces the immediate availability of PHP 5.6.7.
Several bugs have been fixed as well as CVE-2015-0231, CVE-2015-2305 and
CVE-2015-2331. All PHP 5.6 users are encouraged to upgrade to this version.
For source downloads of PHP 5.6.7 please visit our downloads
On Mar 20, 2015, at 16:52, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
My proposal is something similar to Pythons slice, in PHP this would look
like:
$slided = $array[1:4]
This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
ignoring the actual key of the
On Mar 20, 2015, at 3:04 PM, John Bafford jbaff...@zort.net wrote:
If people are generally interested in having an array_key_(first|last|index)
implementation, I can dust off that PR, update it for master, and if we
really need an RFC, I’ll prepare one for PHP 7.1.
-John
I’d be
The latest comments in this thread are talking about having a symbol before
the range to show that it is by positional index. Current propositions for
this are ^ and *.
I'm not sure how such operation would be useful
Anywhere on the front-end where a foreach() is used, and expects at most
say,
On 20 March 2015 at 20:52, Stanislav Malyshev smalys...@gmail.com wrote:
I'm not sure how such operation would be useful, and it definitely would
not be intuitive, as $array[0] and $array[0:1] (assuming non-inclusive
semantic, or [0:0] with inclusive semantics) would return completely
Hi Alex,
On Fri, 2015-03-20, at 13:38, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Certainly it breaks BC (and would presumably have to wait until PHP 8), but
if we were starting from scratch today, why would it make
Certainly it breaks BC (and would presumably have to wait until PHP 8), but
if we were starting from scratch today, why would it make sense to have two
syntaxes that do exactly the same thing?
Maybe you misunderstand me, I am against using two syntaxes for different
things.
That's why I propose a new syntax such as $thing[@0], $thing[@-1]
I have to agree that a new syntax will be required by this.
On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote:
Leigh wrote on 20/03/2015 16:17:
For $thing[-1] I think this only works for strings (and I
Is everybody happy with the RFC being called 'Slice Operator', or is there
a better name for it?
On 20 March 2015 at 18:17, Rowan Collins rowan.coll...@gmail.com wrote:
Leigh wrote on 20/03/2015 16:17:
For $thing[-1] I think this only works for strings (and I have this
implemented, should
Leigh wrote on 20/03/2015 16:17:
For $thing[-1] I think this only works for strings (and I have this
implemented, should probably RFC it)
https://github.com/lt/php-src/tree/string_negative_offset
$thing[-1:] is in scope for arrays though
Why? Getting the last value of an array is just as
On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers bowersb...@gmail.com wrote:
Good day,
My Wiki username is: alexbowers
I have an RFC currently under gauge within the thread (link:
https://marc.info/?l=php-internalsm=142679821024794w=2 )
Which seems to be getting some positive reviews, and so
Grand.
Thank you.
On 20 March 2015 at 19:00, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers bowersb...@gmail.com wrote:
Good day,
My Wiki username is: alexbowers
I have an RFC currently under gauge within the thread (link:
Yes, I'm very conscious of the substantial BC break, which is why I would
target PHP 8 (or even 9, following a deprecation cycle).
I would guess PHP 8, since you can deprecate things at 7.x
Either way, if you make this a separate thread so we don't get off topic,
and i'm sure you'll get many
On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon pjsturg...@gmail.com
wrote:
On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
when we are fixing the low hanging fruits, please directly put in the
wiki that the closing time of a vote has to be announced
From: Stanislav Malyshev [mailto:smalys...@gmail.com]
Does the PHP stat cache include negative cache entries? If not, why
not?
Negative cache is tricky. Most frequent patterns look like this:
1. if(file_exists(blah)) { do stuff }
2. if(!file_exists(blah)) { throw new Exception(no
When you say restrict to one each. Do you mean one for strings and one for
arrays?
If so I'd have to disagree with this, since having the same operation
available to both is less likely to give mistakes. Can you give an example
of an actual benefit for this? Since this would cause a backwards
On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
when we are fixing the low hanging fruits, please directly put in the
wiki that the closing time of a vote has to be announced as a UTC time
so there is no confusion when a day ends.
Good point. I'd still
Alex Bowers wrote on 20/03/2015 16:00:
IMHO, stick to offsets in the first instance, this is a slice
notation, first order of business is to make it behave like
array_slice (+on strings). Assoc key based slicing feels pretty
wrong to me at this point.
I have to agree, we are
On 20 March 2015 at 16:17, Leigh lei...@gmail.com wrote:
$thing[-1:] is in scope for arrays though
How would this work for slicing?
Since doing [@-1:] would mean get the last element to the end.
And doing [@1:-1] is the exact same as doing [@1:] since -1 and blank both
mean the end.
From: Dan Ackroyd [mailto:dan...@basereality.com]
What context are these filesystem hits in, is it class autoloading
by any chance?
Not really. Drupal is looking for 'sites.php' in the root of the web site, and
then probing lower down and finding it. It's also looking for 'settings.php'
Hello!
The PHP development team announces the immediate availability of PHP
5.5.23. Several bugs have been fixed as well as CVE-2015-0231,
CVE-2015-2305 and CVE-2015-2331. All PHP 5.5 users are encouraged to
upgrade to this version.
For source downloads of PHP 5.5.23 please visit our downloads
Alex,
On Fri, 2015-03-20, at 17:19, Alex Bowers wrote:
When you say restrict to one each. Do you mean one for strings and one for
arrays?
Yes, that's what I mean. I would propose square brackets for array offsets,
and curly braces for strings.
If so I'd have to disagree with this, since
From: Alexander Lisachenko [mailto:lisachenko...@gmail.com] said:
I want to mention http://php.net/manual/en/opcache.configuration
.php#ini.opcache.enable-file-override option, that can cache
positive checks information between subsequent requests.
Yes, WinCache's file cache and opcode cache
Hi Alex,
On Fri, 2015-03-20, at 14:52, Alex Bowers wrote:
But I don't think we should only match {} for strings and [] for arrays,
that seems broken to me.
Maybe you misunderstand me, I am against using two syntaxes for different
things.
Based on your reply; yes, I'm definitely
On Mar 20, 2015 4:00 PM, Alex Bowers bowersb...@gmail.com wrote:
IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.
I have to
I'd be tempted to introduce the ability to get a single element by
position as well
Absolutely agree.
Can we agree on a symbol do you think, or should the RFC continue for the
symbol discussion?
IMHO, stick to offsets in the first instance, this is a slice notation,
first order of business is to make it behave like array_slice (+on
strings). Assoc key based slicing feels pretty wrong to me at this point.
I have to agree, we are getting ahead of ourselves.
A quick summary of what
I agree the scope is enough. Going with what Rowan added in about
individual indexes (not slicing) by position to be added in with this,
since the two go together.
In my opinion, the $thing[-1] should be a separate RFC, since it has little
to do with slicing, which is the primary focus of this
On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote:
That’s no different than `@` being invalid because it’s already in use.
The syntax would be [*from:to], which would currently throw a parse error
(since asterisk is required to be placed between two numbers), so this
would be
There’s no existing unary form of * and ^, though, so I think they’d both
be available in this context (^ is my preference).
I think that is also my preference too.
On 20 March 2015 at 20:17, John Bafford jbaff...@zort.net wrote:
On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com
On Fri, Mar 20, 2015 at 11:35 AM, Ferenc Kovacs tyr...@gmail.com wrote:
On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon pjsturg...@gmail.com
wrote:
On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev smalys...@gmail.com
wrote:
Hi!
when we are fixing the low hanging fruits,
On Mar 20, 2015, at 16:27, Alex Bowers bowersb...@gmail.com wrote:
On 20 March 2015 at 20:10, Sean Coates s...@seancoates.com wrote:
That’s no different than `@` being invalid because it’s already in use.
The syntax would be [*from:to], which would currently throw a parse error
(since
On Mar 20, 2015, at 14:17, Rowan Collins rowan.coll...@gmail.com wrote:
It doesn't work *with that syntax*, because -1 is a valid key, just as
$thing[0] can't mean first value of array because it already means value
with key 0. That's why I propose a new syntax such as $thing[@0],
Hi!
My proposal is something similar to Pythons slice, in PHP this would look
like:
$slided = $array[1:4]
This will get the elements in positions 1,2,3,4. (1 through 4 inclusive),
ignoring the actual key of the array. The result for an array will be an
array with the keys preserved, in
The concept itself can still work, but it’d need a token other than @.
This is the symbol currently being used for examples, but thats all it is
currently. Nothing is set in stone (and most likely will change), not just
for this reason but for the reason that I mentioned earlier in the thread
On Mar 20, 2015, at 16:10, Sean Coates s...@seancoates.com wrote:
I posted four suggestions earlier,
They were:
@
*
^
My favourites are the asterisk or caret.
That’s no different than `@` being invalid because it’s already in use.
$ php -a
Interactive shell
php
Alex Bowers wrote:
Anywhere on the front-end where a foreach() is used, and expects at most
say, 10 items. But the full dataset is fetched back (to show a summary
after the first 10 or whatever other reason).
The old code would have required a counter, the new code does not. This
would
Hi Christoph,
On Fri, Mar 20, 2015 at 11:53 AM, Christoph Becker cmbecke...@gmx.de
wrote:
The RFC mentions PHP 7.0 as proposed PHP version. Have you considered
the PHP 7.0 timeline RFC[1]? As I understand it, any RFC put up to
vote after 2015-03-15 cannot target PHP 7.0.
This is usual bug
// alternative old
foreach(array_slice($results, 0, 9) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
Not so bad, in my opinion.
To be the same, your example would have to be:
// alternative old
foreach(array_slice($results, 0, 9, true) as $result) {
echo
Hi Mateusz,
On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski s...@digitalsun.pl
wrote:
Doh, it's happening again, it was discussed before. Anyway, your solution
seems to not fix the real problem behind the bug entry. I suspect that
following scenario may occur:
Of course it was. I
Hi!
I provided an array_key_first() implementation awhile ago that was
first shot down because “too many array_* functions”, and then later
ignored because I didn’t want to go through the RFC process just to
add a few functions. (PR here:
https://github.com/php/php-src/pull/347)
Adding
Hi!
It would give different results, for a reason. There is currently no way
to get an array item by positional index, whilst preserving the keys.
I imagine having such way may be useful. However, reusing array access
syntax for that does not look like a good idea, since it would look like
Why not use array_slice for it?
There certainly are ways to do most of what this RFC covers, however most
of them don't lend themselves well to clean code in my opinion.
Thats why this RFC is listed as being syntactic sugar.
On 20 March 2015 at 21:30, Stanislav Malyshev smalys...@gmail.com
On Mar 20, 2015, at 17:27, Stanislav Malyshev smalys...@gmail.com wrote:
Hi!
I provided an array_key_first() implementation awhile ago that was
first shot down because “too many array_* functions”, and then later
ignored because I didn’t want to go through the RFC process just to
add a
Hi all,
On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski s...@digitalsun.pl
wrote:
Doh, it's happening again, it was discussed before. Anyway, your solution
seems to not fix the real problem behind the bug entry. I
Hi!
To be the same, your example would have to be:
// alternative old
foreach(array_slice($results, 0, 9, true) as $result) {
echo $result . \n; // 1 2 3 4 5 6 7 8 9
}
since this will preserve the array keys.
You're not using the keys in foreach, so why you need to preserve
Hi!
There certainly are ways to do most of what this RFC covers, however
most of them don't lend themselves well to clean code in my opinion.
I must disagree with the notion that clean code can only include
operators and not functions. There's nothing wrong with using functions.
--
Stas
Hi all,
On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Please note that if destroy fails, then new session is not generated,
possible (but ugly) solution is to call session_regenerate_id again.
It just does not work.
How do you keep session for lost session?
On 20 March 2015 at 22:12, Stanislav Malyshev smalys...@gmail.com wrote:
You're not using the keys in foreach, so why you need to preserve them?
This was merely an example of the features equal part in current code, not
a real life use case.
Using the new syntax will keep the keys preserved,
Le 07/03/2015 12:56, Thomas Punt a écrit :
I'd like to put the variadic empty() RFC to vote.
RFC: https://wiki.php.net/rfc/variadic_empty
Hi,
Discussing this RFC with other people at AFUP, we ended up on the -1
side (by a thin margin).
The main reason given against this proposal was that
89 matches
Mail list logo
