Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Le 14/09/2017 à 15:38, Alain Williams a écrit : I vote for making it case sensitive: simpler for the parser; the programmer rapidly learns that it should be 'TRUE' and not 'true' -- job done. No need to force people to switch their code to 'TRUE'. Just supporting case-sensitive 'TRUE',

Re: [PHP-DEV] Deprecate and remove case-insensitive constants?

Hi, Le 12/09/2017 à 14:02, Christoph M. Becker a écrit : Hi everybody! Usually constant identifiers are treated case-sensitive in PHP. This is always the case for constants defined via a `const` declaration. However, define() allows to pass TRUE as third argument to define a case-insensitive

Re: [PHP-DEV] Consider only ignoring newlines for final ?> in a file

Hi Andrea, Le 07/09/2017 à 03:45, Andrea Faulds a écrit : Hi everyone, This is the tiniest of issues, but it's bugged me for a long time and makes the HTML produced by PHP code less readable than it out to be. Specifically, PHP ignores a newline immediately following a ?> tag. The reason

Re: [PHP-DEV] Providing built-in functionality written in PHP (was RE: [PHP-DEV] [VOTE] UUID)

Hi Zeev, Le 06/09/2017 à 16:01, Zeev Suraski a écrit : Thanks for the pointer! I didn't pay close attention to that discussion back then. I do remember François brought it up in a discussion back in 2015 in Paris. For me the issue of security is a major benefit that I don't think was brought

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs in opcode cache

s them, but it's possible to use some stream flag. I suggest stop voting, re-work proposal, provide implementation, and try once again. Thanks. Dmitry. *From:* François Laupretre <franc...@tekwire.net> *Sent:* Thursday, J

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs in opcode cache

Hi Dmitry, Le 22/06/2017 à 09:42, Dmitry Stogov a écrit : The PR is incomplete, so I can't test and even understand the idea completely. In my opinion, user defined streams can't be cached, because the wrapper code itself may be changed from request to request. Right. I hadn't imagined

[PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs in opcode cache

Hi, The message I sent to announce the vote didn't start a new thread. So, here is another one. Opening vote for :https://wiki.php.net/rfc/url-opcode-cache Voting period will end Monday, July 3, 2017, 00:00 UTC. Regards François -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs inopcode cache

Hi, Le 20/06/2017 à 18:35, 江湖大虾仁 a écrit : Hi François, Good work, but I'm not sure if I missed something because I didn't find any discuss relating to this RFC in my mail box, as well as the PR on GitHub. I have a question about the detail of `cache_key`: Discussion :

Re: [PHP-DEV] [RFC][VOTE] Allow loading extensions by name

Hi Sara, Le 19/06/2017 à 23:33, Sara Golemon a écrit : I was about to merge this, but ran into some issues (mostly minor). Could you at least address the fwrite(stderr, ...) item (and preferably clean up the style nits while you're at it)? Oh, and I forgot to include it in the CR, but there

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

a écrit : On Mon, Jun 19, 2017 at 1:30 PM, François Laupretre <franc...@tekwire.net> wrote: I don't know which version you restored, and clicking on the glasses to display differences between versions does not display anything, but I lost the changes I did before the page was overwrit

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

should check the current version. Thanks François Le 19/06/2017 à 20:18, Kalle Sommer Nielsen a écrit : Hi 2017-06-19 20:05 GMT+02:00 François Laupretre <franc...@tekwire.net>: Hi, It seems you just overwrote the RFC main page (https://wiki.php.net/rfc) with your 'retry' RFC (with the '

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs in opcode cache

Hi, Opening vote for : https://wiki.php.net/rfc/url-opcode-cache Voting period will end Monday, July 3, 2017, 00:00 UTC. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [Discussion] Retry functionality

Hi, It seems you just overwrote the RFC main page (https://wiki.php.net/rfc) with your 'retry' RFC (with the 'remove words "visual debt"' change). I tried to follow instructions to revert to the previous revision (select revision and click 'Edit this page') but it does not seem to work (the

Re: [PHP-DEV] [RFC][VOTE] Allow loading extensions by name

Hi, RFC was appoved (17 to 4). Thanks to all who took the time to discuss and vote about this. I just rebased the PR to the current master. Could someone with appropriate rights merge it ? Thanks. Regards François Le 01/06/2017 à 17:18, François Laupretre a écrit : Sorry, forgot [VOTE

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

Hi Pedro, Le 07/06/2017 à 20:23, Pedro Magalhães a écrit : I will not change the target version now during the voting phase. Also because it wouldn't make sense to vote for a feature for 8.0 yet. If the RFC is rejected and the sentiment is that most people would agree with the change but not

Re: [PHP-DEV] Re: [RFC] [VOTE] Arrays starting with a negative index

Hi, Right. Introducing this change is not compatible with the release process, whatever the result of the vote. So, I respectfully ask you to change target to PHP 8 or explain why we should make an exception to the process. Reasons you gave so far are OK for a major version, but not for a

Re: [PHP-DEV] [RFC] [VOTE] Arrays starting with a negative index

Hi, The same for me. Strange to see 7 people willing to introduce such a BC break in a minor version, or did I miss something ? Anyway, +1 to introduce the change in PHP 8. Cheers, François Le 07/06/2017 à 13:31, Derick Rethans a écrit : On Tue, 6 Jun 2017, Pedro Magalhães wrote: Hi all,

[PHP-DEV] About PCS (was : Proposing inclusion of PCS in the 7.2 core distribution)

Hi, thanks to all for taking the time to think about it and give your opinion. It seems that we may gather a consensus on the concept, as most of us seem to agree about the benefits a mechanism like PCS can bring to the core development process in general. It also appears that PCS is not

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Hi Nikita, Le 06/06/2017 à 14:43, Nikita Popov a écrit : Anyway, to get back to the topic of PCS. First, I would recommend to target PHP 7.3 for this change. Feature freeze for 7.2 is in a bit over a month and I think we'll want to make some non-trivial changes to how this works if we

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Hi, Le 06/06/2017 à 17:19, li...@rhsoft.net a écrit : where will this php scripts stored - how do they deal with openbasedir - do you need to place their location in openbasedir while you normally avoid to add anything oustide your application there - and so on Your question proves you

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Le 06/06/2017 à 12:33, li...@rhsoft.net a écrit : Am 06.06.2017 um 12:27 schrieb François Laupretre: What I am proposing here is very different, as the main objective is to dramatically reduce the line count of the core source, without significant performance loss. If we had an army of C

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Hi, Le 06/06/2017 à 11:13, Derick Rethans a écrit : On Tue, 6 Jun 2017, Remi Collet wrote: Sorry, but I don't like the idea of having PHP code bundled in C extension. Have low-level part written in C, and user-land part in PHP is indeed a good way (e.g. mondodb, phpiredis + phredis...), but

Re: [PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Hi, Le 05/06/2017 à 21:26, Fleshgrinder a écrit : I skimmed through the documentation of yours. There is however one question left. Is it possible to have C code that is accessible only to the PHP code of an extensions, instead of all user-level code? As extension PHP code is executed in the

[PHP-DEV] Proposing inclusion of PCS in the 7.2 core distribution

Hi, PCS provides a fast and easy mechanism to mix C and PHP code in PHP extensions (more about PCS at http://pcs.tekwire.net). Thanks to the PHP 7 performance improvement and the inclusion of opcache in the core, a lot of existing non-performance-critical extension code may now be converted

Re: [PHP-DEV] [RFC][Discussion] Add support for stream-wrapped URLs in opcode cache

Hi Dan, Thanks for your comments. Le 03/06/2017 à 15:34, Dan Ackroyd a écrit : However as you declined to respond on Github, I'll ask here again: I am sorry to say that I didn't decline anything, as you never commented the PR. It seems I didn't reply to questions you didn't ask :). I also

Re: [PHP-DEV] [RFC][Discussion] Add support for stream-wrapped URLs in opcode cache

Hi Dan, Thanks for your comments. Both are fixed now. Regards François Le 02/06/2017 à 15:37, Dan Ackroyd a écrit : On 25 May 2017 at 19:17, François Laupretre <franc...@php.net> wrote: Hi, I don't know if it is still time for 7.2 but here is a new RFC to read and comment :

[PHP-DEV] [RFC][VOTE] Allow loading extensions by name

Sorry, forgot [VOTE] in subject... Le 01/06/2017 à 14:46, François Laupretre a écrit : Hi, Feature was discussed last year. I am now opening the vote for a merge in 7.2. URL: https://wiki.php.net/rfc/load-ext-by-name Voting period ends Monday, June 19, 2017, 00:00 UTC. Regards François

[PHP-DEV] [RFC] Allow loading extensions by name

Hi, Feature was discussed last year. I am now opening the vote for a merge in 7.2. URL: https://wiki.php.net/rfc/load-ext-by-name Voting period ends Monday, June 19, 2017, 00:00 UTC. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

[PHP-DEV] [RFC][Discussion] Add support for stream-wrapped URLs in opcode cache

Hi, I don't know if it is still time for 7.2 but here is a new RFC to read and comment : https://wiki.php.net/rfc/url-opcode-cache Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Proposing a new 'cache_key' streams operation

Hi, Le 09/03/2017 à 19:58, Adam Baratz a écrit : Thanks for sharing this. Very interesting idea. Have you posted an RFC yet? That'll help lay out the bigger questions and guide the conversation. There are some notes here if you haven't done one before: https://wiki.php.net/rfc/howto I am

[PHP-DEV] Proposing a new 'cache_key' streams operation

Hi, PR is : https://github.com/php/php-src/pull/1711 This PR creates a mechanism to be used by opcode caches to determine whether a stream-wrapped URI is cacheable, and the key to use when caching it. The first usage for this operation is to opcode-cache the PHP code managed by PCS, which

[PHP-DEV] maintainer-strict-api - A tool to check and enforce encapsulation

Hi, following Joe Watkins' suggestion, I'm reviving a PR I had proposed for 7.0. The PR was abandoned because it was coming too late to target 7.0. The PR is available at : https://github.com/php/php-src/pull/1508 It is introducing a new configure flag. When this flag is set, non-compliant

Re: [PHP-DEV] [RFC][VOTE] Binary String Deprecation

Hi, Le 15/02/2017 à 20:02, Andrey Andreev a écrit : While that's an understandable argument, what happens if we flip it? Is there any benefit to keeping it? If it currently does nothing, and the only reason for keeping it is that it may do something in the future ... Well, there will be

Re: [PHP-DEV] Pipe Operator v2

Le 19/01/2017 à 22:53, Levi Morrison a écrit : On Thu, Jan 19, 2017 at 11:12 AM, François Laupretre <flaupre...@free.fr> wrote: Le 19/01/2017 à 13:54, Levi Morrison a écrit : The `|>` symbol would be the piping operator with these semantics: 1. Evaluate the left-hand side

Re: [PHP-DEV] Pipe Operator v2

Le 19/01/2017 à 13:54, Levi Morrison a écrit : The `|>` symbol would be the piping operator with these semantics: 1. Evaluate the left-hand side. 2. Evaluate the right-hand side. Assert that the result is callable. 3. Pass the result from 1. as the single argument to 2. May I

Re: [PHP-DEV] Binary string forward compatibility removal

Hi, it was stated during the pre-7 discussions, that this flag would be kept for possible future unicode-compliant developments. So, people needing binary strings are still encouraged to use the flag, even if it is not used in the current versions. Regards François Le 06/11/2016 à 20:22,

Re: [PHP-DEV] [RFC] Pipe Operator

Le 16/05/2016 à 19:53, Sara Golemon a écrit : I think you're making a false equivalence here. One can see argument ordering consistency as a serious problem without seeing a Heath Robinson version of call chaining as the solution to it. I appreciate that you want to seize onto any opportunity

Re: [PHP-DEV] [RFC] Pipe Operator

Le 16/05/2016 à 03:33, Larry Garfield a écrit : This still sounds awfully complicated to me. I would far, far prefer the $$ syntax to special casing function aliases just to dance around it. If we had a short-function syntax then requiring a piped function to have only a single argument would

Re: [PHP-DEV] [RFC] Pipe Operator

Le 13/05/2016 à 20:16, Sara Golemon a écrit : for a potential solution to such a long-time issue as argument ordering sadness, IMHO, it's worth the pain. I am currently doing it and I'll send you the list when it is ready. Awesome. Even if not used in this feature, it could potentially be

Re: [PHP-DEV] [RFC] Pipe Operator

Le 14/05/2016 à 18:35, Sara Golemon a écrit : On Sat, May 14, 2016 at 3:33 AM, François Laupretre <franc...@php.net> wrote: Le 14/05/2016 à 01:36, Simon Welsh a écrit : \>> Sure, you could try to use the type of the value being passed in, but that ends up much more magic and

Re: [PHP-DEV] [RFC] Pipe Operator

Le 14/05/2016 à 01:36, Simon Welsh a écrit : I’m not fond of this approach. Take in_array as an example. I have, in the same file, piped an array in as the second argument and piped a string in as the first. To have the position of the piped variable be implicit, you’ll need multiple versions of

Re: [PHP-DEV] [RFC] Pipe Operator

Le 13/05/2016 à 20:16, Sara Golemon a écrit : Just to verify, you're suggesting an end-state something like this? $ret = array(1,2,3) |> array_map(function($x) { return $x * 2; }) // lhs implicitly passed as second arg |> array_sum(); // implicitly passed as only arg (first position) //

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, Le 13/05/2016 à 00:41, Sara Golemon a écrit : So we'd have to audit all 4k+ functions in the PHP runtime (and provide a mechanism for defining it on userspace functions)? That's right, except that, if we only consider functions accepting more than 1 arg, we just need to check about

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

Le 13/05/2016 à 15:30, Rowan Collins a écrit : If somebody adds something that is genuinely irrelevant (e.g. based on a simple misunderstanding of the RFC) then somebody else (*anyobdy* else) could remove it. Maybe I am not candid enough but do you imagine what it could become on a

Re: [PHP-DEV] [RFC] [Discussion] Third-party editing of RFCs

Le 12/05/2016 à 19:33, Sara Golemon a écrit : https://wiki.php.net/rfc/rfc.third-party-editing Let's make RFCs more useful before AND after voting! -Sara As RFC author, what should I do with irrelevant arguments against my RFC ? Should I add a reply ? More generally, I don't like the idea

Re: [PHP-DEV] [RFC] Pipe Operator

Hi Sara, Le 12/05/2016 à 19:02, Sara Golemon a écrit : On Thu, May 12, 2016 at 5:48 AM, Zeev Suraski wrote: Whether it's $$ or !# or $0 or any other random symbol doesn't really matter. Agreed. Here we have a completely optional syntactic sugar, that's not nearly as widely

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Le 11/05/2016 à 06:59, Joe Watkins a écrit : Morning, In this case, it is currently impossible to write a single configuration file that will work in both environments, forcing developers to manually maintain two separate versions of the file. I'm aware this has been mentioned in this

Re: AW: [PHP-DEV] [RFC] Allow loading extensions by name

Le 11/05/2016 à 08:20, Christian Stoller a écrit : -Ursprüngliche Nachricht- Von: François Laupretre [mailto:franc...@php.net], Gesendet: Dienstag, 10. Mai 2016 15:23 Please read and comment : https://wiki.php.net/rfc/load-ext-by-name Regards François Why not just naming them

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi, Le 10/05/2016 à 22:07, Lester Caine a écrit : Windows did not worry about which extension was used in the past, but nowadays the problem is ensuring the correct build of extension is accessed and while 32bit is still the safer base, it's all too easy to get them mixed up with 64bit builds.

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi Lester, Le 10/05/2016 à 21:01, Lester Caine a écrit : The idea has been proposed before, but the addition of php_ for windows installs has not been universally applied. Extensions like eAccelerator, adodb and other third party extensions that did not form part of the windows 'installation'

Re: [PHP-DEV] [RFC] Allow loading extensions by name

Hi, Le 10/05/2016 à 18:54, Stanislav Malyshev a écrit : The RFC says " it is currently impossible to write a single configuration file that will work in both environments" - but even with extension fix, wouldn't it be still impossible since Windows are Unix paths would probably be different?

[PHP-DEV] [RFC] Allow loading extensions by name

Please read and comment : https://wiki.php.net/rfc/load-ext-by-name Regards François --- L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast. https://www.avast.com/antivirus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] run-tests.php improvement for PHP 7.0+

Hi Derick, Le 09/05/2016 à 20:36, Derick Rethans a écrit : Hi! I've recently been having some looks at issues between xdebug and opcache, and this meant that I need to write a test case for it. Ages ago I added support for the "--EXTENSIONS--" section in .phpt files, to load extensions that

Re: [PHP-DEV] [RFC] Pipe Operator

Ho Rowan, Le 01/05/2016 01:14, Rowan Collins a écrit : On 29/04/2016 20:58, Sara Golemon wrote: This is one of my favorites out of HackLang. It's pure syntactic sugar, but it goes a long way towards improving readability. https://wiki.php.net/rfc/pipe-operator I like this idea, for the same

Re: [PHP-DEV] Proposal: Startup snapshot for optimizing app load time

Hi, Le 13/04/2016 17:55, Lin Yo-An a écrit : Hi internals, The javascript engine V8 uses a strategy called "startup snapshot" to optimize app load time (see http://v8project.blogspot.tw/2015/09/custom-startup-snapshots.html for more details) The approach used by V8 creates a snapshot from

Re: [PHP-DEV] [RFC Discussion] Typed Properties

Hi, Le 16/03/2016 17:36, Phil Sturgeon a écrit : Hello everyone, I have completed the draft for an RFC, to add Typed Properties. The patch has been written by the one and only Joe Watkins. https://wiki.php.net/rfc/typed-properties Maybe you can add a reference to a discussion we had some

[PHP-DEV] Re: [RFC][VOTE] Generalize support of negative string offsets

Le 19/02/2016 13:19, François Laupretre a écrit : Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Vote is over. RFC is approved with a score of 28 Yes to 0 No. Thanks to all who took time for discussion and vote. Can someone please review and merge the PR

Re: [PHP-DEV] [RFC] Deprecations for PHP 7.1

Hi, Le 18/02/2016 13:41, Nikita Popov a écrit : This RFC is incomplete -- I'm posting it now so people can suggest other things that should be deprecated. I expect it to grow over time and don't plan to vote on it in the immediate future. May I suggest to remove the second argument of

[PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets

Hi, (sorry, posting again to force new thread) Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends in 2 weeks : Monday, March 7th 00:00 UTC. As, during the discussion, we talked about many related but off-topic subjects, please remember that the subjects

Re: [PHP-DEV] [RFC Proposal] var keyword deprecation/removal

Hi, Le 18/02/2016 20:10, Colin O'Dell a écrit : Hello everyone, I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. My understanding is that this keyword was kept in PHP 5 for backwards-compatibility with PHP 4. However, it's been 9 years since PHP 4 was

Re: [PHP-DEV] Re: [RFC][VOTE] Generalize support of negative string offsets

Le 19/02/2016 00:48, Andrea Faulds a écrit : You might have to make yet another post. This last one had a new subject, but it still was marked as a reply, so my news client threads it in with the original thread. Just posted the message once again. Still appears in the same thread. It seems

[PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets

Hi, Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below remain out of scope of this RFC and deserve their own thread :

[PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets

Hi, (sorry, posting again with modified subject to force new thread) Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below

Re: [PHP-DEV] [RFC][VOTE] Generalize support of negative string offsets

Hi, Starting vote about : https://wiki.php.net/rfc/negative-string-offsets Voting period ends Friday, March 4th 00:00 UTC. As, during the discussion, we talked about many related subjects, please remember that the subjects below remain out of scope of this RFC and deserve their own thread :

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Hi, Le 17/02/2016 00:26, Yasuo Ohgaki a écrit : I noticed one issue on {} https://bugs.php.net/bug.php?id=71611 echo "${str{1}}"; raises syntax error while echo "{$str{1}}"; works. Is this addressed? No, this is a different problem. This RFC just adds support for negative index values.

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 15/02/2016 04:49, Stanislav Malyshev a écrit : Hi! This fix has been merged into master (targeting 7.1), thanks! I'm not sure that was such a good idea (sorry, didn't have time to write about it before the weekend). Introducing a new warning into previously working code is a BC break, and

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 11/02/2016 13:16, Christoph Becker a écrit : Appending to an array always adds a single element only, consider $a = [1,2,3]; $a[] = [4,5]; The suggested syntax for strings would concatenate an arbitrary amount of elements (characters) to a string. IMHO, this would not be consistent,

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 11/02/2016 13:46, Rowan Collins a écrit : Christoph Becker wrote on 11/02/2016 12:16: Appending to an array always adds a single element only, consider $a = [1,2,3]; $a[] = [4,5]; The suggested syntax for strings would concatenate an arbitrary amount of elements (characters) to a

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

String offsets are full of oddities : $str = "abc"; $str{0} = ''; var_dump($str); // -> string(3) "bc" (read as "\0bc") Assigning an empty string to a string offset inserts a null byte because the string length is not checked in zend_assign_to_string_offset(). I see this as a bug. IMO, this

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 11/02/2016 17:25, Andrea Faulds a écrit : Hi François, François Laupretre wrote: String offsets are full of oddities : $str = "abc"; $str{0} = ''; var_dump($str); // -> string(3) "bc" (read as "\0bc") Assigning an empty string to a string offset inser

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 10/02/2016 15:34, Dan Ackroyd a écrit : On 10 February 2016 at 07:00, Yasuo Ohgaki wrote: Additional comment on this php > $v=array(1,2,3); php > $v .= 'abc'; I think $v .= 'abc' should not destroy array variable. It's minor issue, though. That is the current

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Hi, I just added support for '[]' on strings and '{}' to the PR. Examples : $string[] = 'a'; // equivalent to : $string[strlen($string)] $string{} = 'a'; // For consistency With this change, AFAIK, '{}' and '[]' notations are handled exactly the same way (the only difference was that the

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 11/02/2016 07:27, Stanislav Malyshev a écrit : Hi! I just added support for '[]' on strings and '{}' to the PR. Examples : $string[] = 'a'; // equivalent to : $string[strlen($string)] $string{} = 'a'; // For consistency That's probably not a good idea, and certainly is not good for the

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Hi, Slightly off-topic but, as I was looking for the way to add support for '$str[]=' assignments, I found something strange. Just for curiosity, does someone know a reason for this : $str = "abc"; $str[1]="z"; var_dump($str); // -> string(3) "zbc" -> Expected $str = ""; // Empty string

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 06/02/2016 16:16, Nikita Popov a écrit : In any case, while this is no doubt an interesting question, and one we should resolve, it is tangential to this RFC and this RFC should make no recommendations either way. I would prefer not to be forced to vote against this RFC due to the inclusion

Re: [PHP-DEV] [RFC] Generalize support of negative string offsets

Le 31/01/2016 23:14, Stanislav Malyshev a écrit : Hi! The only concern I have is that support of negative indexing will break symmetry with (proper) arrays, where we cannot support negative indexing. I think that was the main source of objections to this proposal in the past. However, as one

Re: [PHP-DEV] Allow loading extensions by name

Hi, Le 29/01/2016 08:09, Martin Keckeis a écrit : Hello, 2016-01-28 21:20 GMT+01:00 François Laupretre <franc...@php.net>: Hi, Can you please give your thoughts about a PR I just created : https://github.com/php/php-src/pull/1741 Loading extensions by name (instead of file name) pr

[PHP-DEV] Allow loading extensions by name

Hi, Can you please give your thoughts about a PR I just created : https://github.com/php/php-src/pull/1741 Loading extensions by name (instead of file name) provides a portable way of specifying extensions in an INI file. Example : extension=bz2 zend_extension=xdebug This will be converted

Re: [PHP-DEV] Severe safety fail in file access and stream filters

Le 26/01/2016 11:50, Julien Pauli a écrit : I think what we should do is sit around the table with people interested (Daniel Lowrey may be one of them), and plan a full rewrite of streams for PHP next major (PHP 8). I don't think addind stuff to next minors is a good idea, knowing we must

Re: [PHP-DEV] Re: [RFC] Generalize support of negative string offsets

Hi Andrea, Le 23/01/2016 22:10, Andrea Faulds a écrit : Er, ignore what I just said. Negative string offsets are actually special-cased and always produce an "Unitialized string offset" or "Invalid string offset" notice. So our current behaviour is in fact completely useless, not just mostly.

[PHP-DEV] [RFC] Generalize support of negative string offsets

Hi, Starting discussion about https://wiki.php.net/rfc/negative-string-offsets Please read and comment. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Handling of withdrawn RFCs

Hi, Le 21/01/2016 21:33, Flyingmana a écrit : As already was noted by someone else, seeing an RFC as failed if it gets withdrawn has some serious downsides and potential to get abused. >... Would we need some rules in case multiple people want to take it over, or should we say the first one

Re: [PHP-DEV] WIKI: phpng-upgrading

Le 20/01/2016 23:07, Sean DuBois a écrit : On Thu, Jan 21, 2016 at 06:55:41AM +0900, Yasuo Ohgaki wrote: Hi ZendEngine developers, I'm not sure if the wiki page is maintained, but I noticed few errors. https://wiki.php.net/phpng-upgrading#strings has following example. - ZVAL_STRING(zv, str,

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

Le 14/01/2016 16:47, Stig Bakken a écrit : I agree whole-heartedly with Zeev here! Anyone who has a clue about organizational psychology will tell you to focus on what you want more of, not on what you want to eliminate. Heck, anyone who is a parent today should understand this intuitively.

Re: [PHP-DEV] Re: Internals and Newcomers and the Sidelines -- "let's proceed to ideas"

Hi, As we are talking about newcomers and the way we should encourage them, may I suggest you all to read Dustin's 'friend class' RFC (https://wiki.php.net/rfc/friend-classes). That's his first RFC and he got only one (negative) reply. Whether you like it or not, his work deserves being read

Re: [PHP-DEV] Close some old issues

Le 15/01/2016 18:04, Dan Ackroyd a écrit : If anyone thinks they all ought to be kept open, that could be discussed on list, but I would really like to avoid discussing each one individually on list, as I don't think that would be productive. If anyone with wants to keep any of these issues

Re: [PHP-DEV] Close some old issues

Le 15/01/2016 19:53, Stanislav Malyshev a écrit : Hi! Those that do require RFC I think is fine to close. Maybe have a standard text for that - like "This request describes a change that is substantial enough to warrant an RFC. Please read and submit an RFC for the consideration for the

Re: [PHP-DEV] Re: Anonymous voting on wiki

Le 12/01/2016 20:29, Ferenc Kovacs a écrit : On Tue, Jan 12, 2016 at 5:00 PM, François Laupretre <franc...@php.net> wrote: Le 12/01/2016 15:52, Dan Ackroyd a écrit : François Laupretre wrote: I would like the process to be amended to disable posting opinions/discussions about an RFC

Re: [PHP-DEV] Re: Anonymous voting on wiki

Le 12/01/2016 15:52, Dan Ackroyd a écrit : François Laupretre wrote: I would like the process to be amended to disable posting opinions/discussions about an RFC while the vote is open, considering there was enough time for that during the discussion phase. This is not a good idea

Re: [PHP-DEV] Re: Anonymous voting on wiki

Hi Eli, Le 11/01/2016 15:45, Eli a écrit : On 1/10/16 8:15 AM, Dennis Birkholz wrote: I would really like to understand the rational behind anonymous voting in the PHP internals context. Votes for RFCs should be purely based on technical reasons and whether the language change would benefit

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

Le 11/01/2016 23:55, Anthony Ferrara a écrit : There are two prime reasons people may avoid internals (at least related to this discussion). 1. Don't want to deal with the aggressive tone of the list 2. Don't want to expose themselves to targeted aggression/negativity If we want to deal with

Re: [PHP-DEV] Anonymous voting on wiki

Le 09/01/2016 08:55, Stanislav Malyshev a écrit : Hi! Since in CoC discussion it was mentioned we may need anonymous voting, I've created a patch that allows anonymous polls to be created: https://github.com/php/web-wiki/pull/7 The results still recorded per user, but everybody can see just

Re: [PHP-DEV] [RFC] Class Friendship

Hi Dustin, thanks for this nice work ! Here are some comments and thoughts : * There is another inheritance property I didn't include in my initial article, and I think that should be described : class Base { friend BaseFriend; protected $base_prop; static protected

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

Le 07/01/2016 10:03, Peter Cowburn a écrit : Just replying on the anonymous RFC votes side-topic. That's another question. Ideally, votes should be anonymous, even on RFCs. Scalar type hints have proved that seeing other's vote may be a very bad thing. This was tried once [1] and there was

Re: [PHP-DEV] [RFC] Warn about invalid strings in arithmetic

Hi Andrea, Le 08/01/2016 01:03, Andrea Faulds a écrit : Hi everyone, I'm proposing a new RFC to make it easier to spot errors when using PHP's arithmetic operators: https://wiki.php.net/rfc/invalid_strings_in_arithmetic Please read it and tell me your thoughts. Thanks! I would suggest we

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

Le 07/01/2016 21:50, Zeev Suraski a écrit : -Original Message- From: Anthony Ferrara [mailto:ircmax...@gmail.com] Sent: Thursday, January 07, 2016 8:15 PM To: internals@lists.php.net Subject: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct All, On Mon, Jan 4, 2016 at 4:06 PM, Anthony

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

Hi, Le 06/01/2016 16:21, Anthony Ferrara a écrit : > I have received no less than 4 direct threats of violence that were directly due to my involvement > with the Scalar Type Declarations RFC. I'm surprised it went to that point but I'm glad you're talking about the STH saga, because this

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

Le 06/01/2016 19:56, Sara Golemon a écrit : First, I didn't accuse you of anything. My response to your private email, was a private email back saying "hey, I don't know why you're so angry and name-cally, but go ahead and move forward with your version. I just didn't want it to get left on

Re: [PHP-DEV] Re: [RFC] [Draft] Adopt Code of Conduct

Le 06/01/2016 20:23, Andrea Faulds a écrit : Hi, Sara Golemon wrote: So, I'm all for a mediation team, but no sanction, even temporary, without a public vote. I'm glad you and I agree on this. There is the risk with public votes that whoever votes a particular way gets harassed for the way

Re: [PHP-DEV] [RFC] [Draft] Adopt Code of Conduct

Le 06/01/2016 20:38, Ryan Pallas a écrit : I agree, a conflict resolution document *and team* seems infinitely better. This team's job is to resolve things quietly and without further incident, however if action may be required - its an open vote (as previously suggested). Agreed. 'Don't be

  1   2   3   4   5   >