[PHP-DEV] Ten years estimated Plan to replace PHP’s inconsistent API

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 will

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

On Fri, Mar 20, 2015 at 7:30 PM, Pierre Joye wrote: > hi, > > On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon > 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

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

hi, On Tue, Mar 17, 2015 at 5:01 AM, Philip Sturgeon 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 > restricting the sale of f

[PHP-DEV] VCS Account Request: tgdice

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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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. Exactl

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 23:03, Stanislav Malyshev 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 array which is a

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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];

Re: [PHP-DEV] [VOTE] Make empty() a Variadic

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 it

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 22:12, Stanislav Malyshev 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, therefore any examp

Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data

Hi all, On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki 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? > > Lost session

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 M

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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

Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data

Hi all, On Sat, Mar 21, 2015 at 6:43 AM, Yasuo Ohgaki wrote: > On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski > 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 scenar

Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data

Hi Mateusz, On Fri, Mar 20, 2015 at 7:12 PM, Mateusz Kocielski 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 remember well. Discuss

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 17:27, Stanislav Malyshev 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 few function

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 wrote: > Hi! > > >

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > // 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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 ex

[PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates awarning and loses session data

Hi Christoph, On Fri, Mar 20, 2015 at 11:53 AM, Christoph Becker 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 fix. Regar

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 > woul

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 20:52, Stanislav Malyshev 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 > different things. That

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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, 1

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> On Mar 20, 2015, at 3:04 PM, John Bafford 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 very inter

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:52, Stanislav Malyshev 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 t

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 p

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:27, Alex Bowers wrote: > On 20 March 2015 at 20:10, Sean Coates 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 place

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

On Fri, Mar 20, 2015 at 11:35 AM, Ferenc Kovacs wrote: > On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon > wrote: > > > On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev > > > wrote: > > > Hi! > > > > > >> when we are fixing the low hanging fruits, please directly put in the > > >> wiki that

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 wrote: > > On Mar 20, 2015, at 16:10, Sean Coates wrote: > > >> I posted four sug

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 20:10, Sean Coates 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 different. Alternati

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 16:10, Sean Coates 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 >

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> 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 > define('a', 1); php > define('b', 2); php > echo @a . "\n"; 1 php > echo

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015, at 14:17, Rowan Collins 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], > $thing[@-1], etc. I wo

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 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 probably RFC it)

Re: [PHP-DEV] RFC Karma

Grand. Thank you. On 20 March 2015 at 19:00, Ferenc Kovacs wrote: > > On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers wrote: > >> Good day, >> >> My Wiki username is: alexbowers >> >> I have an RFC currently under gauge within the thread (link: >> https://marc.info/?l=php-internals&m=142679821024

Re: [PHP-DEV] RFC Karma

On Fri, Mar 20, 2015 at 2:56 PM, Alex Bowers wrote: > Good day, > > My Wiki username is: alexbowers > > I have an RFC currently under gauge within the thread (link: > https://marc.info/?l=php-internals&m=142679821024794&w=2 ) > > Which seems to be getting some positive reviews, and so I would lik

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

On Fri, Mar 20, 2015 at 7:14 PM, Philip Sturgeon wrote: > On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev > 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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 wrote: > Leigh wrote on 20/03/2015 16:17: > >> >> For $thing[-1] I think this only works for strings (and I have this >> im

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 man

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 h

Re: [PHP-DEV] Only Vote on Votes Initiated After Registration

On Mon, Mar 16, 2015 at 2:59 PM, Stanislav Malyshev 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 allow other t

[PHP-DEV] PHP 5.5.23 is available

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 pa

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 inco

RE: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

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 Ex

RE: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

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'

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 misunder

RE: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

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 cach

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 16:17, Leigh 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.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 RFC

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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?

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015 4:00 PM, "Alex Bowers" 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 agree, we are get

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 ge

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

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: `pre

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015 2:59 PM, "Alex Bowers" 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 look

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 perfor

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 se

[PHP-DEV] RFC Karma

Good day, My Wiki username is: alexbowers I have an RFC currently under gauge within the thread (link: https://marc.info/?l=php-internals&m=142679821024794&w=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, A

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 > comple

[PHP-DEV] PHP 5.6.7 is available

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 page

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 like

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 [] fo

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 in

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

Hey: On Fri, Mar 20, 2015 at 7:53 PM, Alain Williams 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 wrote: >> > Hi internals, >> >> Hi internals, >> >> >> >> The RFC to add a user-land function for an easy-to-use and reliable >>

Re: [PHP-DEV] RFC - Array slice syntactic sugar

Alex Bowers wrote on 20/03/2015 13:09: On 20 March 2015 at 13:04, Rowan Collins > 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 jus

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > $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, as

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 13:04, Rowan Collins 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?

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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 delet

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015 12:33 PM, "Alex Bowers" 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 overwrite/r

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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!

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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?

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On Mar 20, 2015 11:40 AM, "Alex Bowers" 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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

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];

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

On Fri, Mar 20, 2015 at 10:46:58PM +1100, Pierre Joye wrote: > On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai 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: > >> htt

Re: [PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

On Fri, Mar 20, 2015 at 7:03 PM, Wei Dai 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 addin

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 bee

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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 t

Re: [PHP-DEV] RFC - Array slice syntactic sugar

> > 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

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 at 10:38, Leigh 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 itself worked.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 19 March 2015 at 21:03, Larry Garfield wrote: > Variations of this proposal have been discussed many times. I don't > recall what the pushback was but it's worth your time to check the archives > to see what the objections were and if you can address them, and/or if the > new engine in PHP 7

Re: [PHP-DEV] Question/comment about the Array to String conversion RFC

2015.03.19. 18:40 ezt írta ("Dan Ackroyd" ): > > On 19 March 2015 at 17:14, François Laupretre 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 to fatal error won't require

Re: [PHP-DEV] Re: Bug #69127 session_regenerate_id(true) randomly generates a warning and loses session data

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.

Re: [PHP-DEV] RFC - Array slice syntactic sugar

On 20 March 2015 01:28:53 GMT, Alex Bowers 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 mean by 's

Re: [PHP-DEV] [Q] Does PHP have a negative cache for file stat operations?

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 : > Hi! > > > We're doing some performance work in WinCache,

[PHP-DEV] 回复： [RFC][DISCUSSION] Add preg_replace_callback_array function

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()` th

[PHP-DEV] PHP 5.4.39 Released

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 pleas