Re: [PHP-DEV] [RFC] PHP Attributes

Hi all, First of all thanks dmitry for your great work and for bringing the RFC back to life. I think it would be great to allow users to define their own annotations and give them some structure (what the annotation is made of). For example let's say I apply an annotation to define that a

Re: [PHP-DEV] [RFC:generics]

On Wed, Apr 27, 2016 at 6:50 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > Hi all, > > Yesterday I spent a considerable 2h talking about Generics in Doctrine > channel. > We discussed the specifics of each boundary that PHP's implementation could > take advantage. Here are

Re: [PHP-DEV] [RFC] IntlCharsetDetector

Hi Sara, On Wed, Apr 27, 2016 at 1:10 AM, Sara Golemon wrote: > On Tue, Apr 26, 2016 at 2:06 AM, Yasuo Ohgaki wrote: >> Things might have been changed, but as you've mentioned encoding >> detection is unstable and ICU is poor compared to mbstring's detection

Re: [PHP-DEV] [RFC:generics]

I'm also a little fussy on lower bounds use cases. One of my brain waves to eliminate the need for reflection changes was to use a C++ templates like system. In effect the generic type, becomes a template with which all use cases spawn (cachable) spooled classes with all type aliases filled in.

Re: [PHP-DEV] [RFC] PHP Attributes

It would, but the short array syntax followed by a function/method decl would be unambiguous. On dmitry's note, I'm not sure maintaining similarity with Hack is justified. While Facebook maintains it as an open source project, they primarily built it for themselves, so I can only think they will

Re: [PHP-DEV] [RFC] IntlCharsetDetector

Hi! > For me, the difference is that I expect further work to be done on > improving ICU, while I lack that confidence for mbstring. If the API My experience over the years has been that established supported libraries like ICU usually have better track record in improving and maintenance than

[PHP-DEV] Re: Property Guards Optimization

great. thanks. From: Nikita Popov Sent: Wednesday, April 27, 2016 00:15 To: Dmitry Stogov Cc: internals Subject: Re: Property Guards Optimization On Tue, Apr 26, 2016 at 10:49 PM, Dmitry Stogov >

[PHP-DEV] Re: Property Guards Optimization

On Tue, Apr 26, 2016 at 10:49 PM, Dmitry Stogov wrote: > Hi Nikita, > > > Could you please review the patch > https://gist.github.com/dstogov/22813388180fd4c1d7b0ead35715b067 > > > This is an implementation of your idea about specialized version for > single active guard. > > I

Re: [PHP-DEV] [RFC:generics]

Hi all, Yesterday I spent a considerable 2h talking about Generics in Doctrine channel. We discussed the specifics of each boundary that PHP's implementation could take advantage. Here are our findings, which I'll illustrate using Java equivalents: 1- Upper bounds (T extends A) We all

[PHP-DEV] Property Guards Optimization

Hi Nikita, Could you please review the patch https://gist.github.com/dstogov/22813388180fd4c1d7b0ead35715b067 This is an implementation of your idea about specialized version for single active guard. I hope, everything is fine, all tests are passed. Thanks. Dmitry.

AW: [PHP-DEV] [RFC:generics]

> -Ursprüngliche Nachricht- > Von: Rasmus Schultz [mailto:ras...@mindplay.dk] > Gesendet: Montag, 25. April 2016 18:09 > An: Josh Di Fabio > Cc: Dominic Grostate; Guilherme Blanco; Mathieu Rochette; Ben Scholzen > 'DASPRiD'; Sara Golemon; PHP internals; Mathieu > Rochette > Betreff: Re:

Re: [PHP-DEV] [RFC] PHP Attributes

On 4/25/2016 10:31 AM, Dmitry Stogov wrote: > > > On 04/23/2016 06:29 PM, Fleshgrinder wrote: >> +1 for the basic idea, however, I have various remarks. >> >> The RFC text is hard to read and contains many grammatical mistakes. How >> could one help you here? > I would need a co-author :) > I

[PHP-DEV] Request for account approval

Hi, This is Tom and I Work as a PHP develpoper. I want to sharre my knowledge with you and also want to gain some knowledge from you. So please approve my request. Thanks Tom

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 4/26/2016 9:40 PM, Levi Morrison wrote: > I think he meant to post a different case: > > function (Foo $foo = null, $concrete_param); > > This is based on a conversation I've had with him elsewhere. > Gosh, I know such code. That should result in an error! :P -- Richard "Fleshgrinder"

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 1:34 PM, Fleshgrinder wrote: > On 4/26/2016 9:13 PM, Bob Weinand wrote: >> There's undefined (= not a value) and there's the value null. We just don't >> expose undefined to userland. [You see it when accessing undefined >> variables, which PHP

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 4/26/2016 9:13 PM, Bob Weinand wrote: > There's undefined (= not a value) and there's the value null. We just don't > expose undefined to userland. [You see it when accessing undefined variables, > which PHP converts to null with a notice for example.] > > Null is definitely a value. You can

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On 4/26/2016 10:38 AM, Alexander Lisachenko wrote: > Hello, Nikita! > > It's a great news! Having this stuff in the 7.1 core is awesome! > > But I have several petitions for this API: > 1) Could it avoid using of raw functions for parsing API, like > ast\parse_file or ast\parse_code > 2) Could

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

> Am 26.04.2016 um 19:41 schrieb Niklas Keller : > > 2016-04-26 19:33 GMT+02:00 Bob Weinand >: > > Am 26.04.2016 um 19:00 schrieb Niklas Keller > >: > > > > 2016-04-26 16:58

Re: [PHP-DEV][RFC] Callable Types

Bringing this thread to the main one On Sun, 24 Apr 2016 06:27:39 +0300, Mathieu Rochette wrote: I've seen someone mentioning variadics so I made a few small tests, I think those two should work (they currently don't): https://3v4l.org/eZgR9/rfc#rfc-callable_typehint

Re: [PHP-DEV] [RFC] PHP Attributes

And it will probably be in conflict with the Short Array Syntax ? On 26 April 2016 at 13:14, Dmitry Stogov wrote: > Just because HHVM is closer to PHP than C#. > > > > From: Dominic Grostate > Sent: Tuesday, April

Re: [PHP-DEV][RFC] Callable Types

On Sat, 23 Apr 2016 20:44:27 +0300, Jesse Schalken wrote: I see. So it's the combination of not erroring when more parameters are passed than a function accepts, and >permitting methods to add extra optional parameters that is wrong. So without the former being

Re: [PHP-DEV] Re: [RFC] [Discussion] Octal overflow detection

Den 2016-04-19 kl. 01:24, skrev Sara Golemon: On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon wrote: https://wiki.php.net/rfc/octal.overload-checking Because having this expression evaluate to true makes me sad: ("\000" === "\400") I haven't heard any responses on this and

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

2016-04-26 19:33 GMT+02:00 Bob Weinand : > > Am 26.04.2016 um 19:00 schrieb Niklas Keller : > > > > 2016-04-26 16:58 GMT+02:00 Bob Weinand : > > > >> Yeah, I'd like to not allow ?Foo in any case if union types pass. > >> > > > > What's

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

> Am 26.04.2016 um 19:00 schrieb Niklas Keller : > > 2016-04-26 16:58 GMT+02:00 Bob Weinand : > >> Yeah, I'd like to not allow ?Foo in any case if union types pass. >> > > What's the reason for that? To me, null is neither a type nor should it be. I

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 11:20 AM, Levi Morrison wrote: > On Tue, Apr 26, 2016 at 11:00 AM, Niklas Keller wrote: >> 2016-04-26 16:58 GMT+02:00 Bob Weinand : >>> >>> Yeah, I'd like to not allow ?Foo in any case if union types pass. >>

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

On 26.04.2016 at 19:10, Peter Cowburn wrote: > Am I correct in understanding that no further candidates or volunteers for > the position will be considered at this time? Anatol mailed the list about the need to have RMs for 7.1 on April, 12th, and suggested to start voting on April, 26th (two

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 11:00 AM, Niklas Keller wrote: > 2016-04-26 16:58 GMT+02:00 Bob Weinand : >> >> Yeah, I'd like to not allow ?Foo in any case if union types pass. > > > What's the reason for that? To me, null is neither a type nor should it be. On

Re: [PHP-DEV] [RFC] PHP Attributes

Just because HHVM is closer to PHP than C#. From: Dominic Grostate Sent: Tuesday, April 26, 2016 19:43 To: Dmitry Stogov Cc: rowan.coll...@gmail.com; PHP internals; Stanislav Malyshev Subject: Re: [PHP-DEV] [RFC] PHP Attributes Why

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

On 26 April 2016 at 17:48, Julien Pauli wrote: > On Tue, Apr 26, 2016 at 6:37 PM, Michael Wallner wrote: > > On 26/04/16 17:59, Anatol Belski wrote: > >> Hi, > >> > >> herewith I would like to call everyone to go vote for the 7.1 RMs team. > The > >> poll is opened

Re: [PHP-DEV] [RFC] PHP Attributes

Why not like C#? [Description("My Function")] function my_function() {} Without the semicolon, this wouldn't be valid in any other context. On 26 Apr 2016 8:41 a.m., "Dmitry Stogov" wrote: On 04/25/2016 11:20 PM, Stanislav Malyshev wrote: > Hi! > > No, but this is valid: >>

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

2016-04-26 16:58 GMT+02:00 Bob Weinand : > Yeah, I'd like to not allow ?Foo in any case if union types pass. > What's the reason for that? To me, null is neither a type nor should it be.

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 4/26/16 10:58 AM, Bob Weinand wrote: Yeah, I'd like to not allow ?Foo in any case if union types pass. If they fail, ?Foo is fine for me. I am persuaded that using the HHVM grammar is best. I personally don't like but it makes sense. If the Union RFC would propose only the | grammar and

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

On Tue, Apr 26, 2016 at 6:37 PM, Michael Wallner wrote: > On 26/04/16 17:59, Anatol Belski wrote: >> Hi, >> >> herewith I would like to call everyone to go vote for the 7.1 RMs team. The >> poll is opened under >> >> https://wiki.php.net/todo/php71 >> >> The vote starts on

Re: [PHP-DEV] [VOTE] 7.1 RMs selection

On 26/04/16 17:59, Anatol Belski wrote: > Hi, > > herewith I would like to call everyone to go vote for the 7.1 RMs team. The > poll is opened under > > https://wiki.php.net/todo/php71 > > The vote starts on 2016-04-26 and end on 2016-05-03 (both at a time 6pm). Thanks! PS: If anyone is

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 4/26/16 12:21 PM, Christoph Becker wrote: On 26.04.2016 at 16:24, Dmitry Stogov wrote: At first, I'm glad this implementation is ready. At least it's possible to analyze its profs and cons. I'm also sure that both RFCs have their opponents and advocates. Now, I just like to make the final

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 26.04.2016 at 16:24, Dmitry Stogov wrote: > At first, I'm glad this implementation is ready. > At least it's possible to analyze its profs and cons. > I'm also sure that both RFCs have their opponents and advocates. > > Now, I just like to make the final voting fair. I'm a bit confused, as

Re: [PHP-DEV] [RFC] IntlCharsetDetector

On Tue, Apr 26, 2016 at 2:06 AM, Yasuo Ohgaki wrote: > Things might have been changed, but as you've mentioned encoding > detection is unstable and ICU is poor compared to mbstring's detection > at least for Japanese encodings. > For me, the difference is that I expect further

[PHP-DEV] [VOTE] 7.1 RMs selection

Hi, herewith I would like to call everyone to go vote for the 7.1 RMs team. The poll is opened under https://wiki.php.net/todo/php71 The vote starts on 2016-04-26 and end on 2016-05-03 (both at a time 6pm). Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Balls.. Void my last comment.. On 26 Apr 2016 4:42 p.m., "Dominic Grostate" wrote: > Is this RFC going to play nice with Void return types? > > If we get unions, then doesn't it follow that the declaration goes as this? > > function foo(A | B $val = null): JustChill |

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Is this RFC going to play nice with Void return types? If we get unions, then doesn't it follow that the declaration goes as this? function foo(A | B $val = null): JustChill | void {} That's a nullable typehint and a nullable return type surely. On 26 Apr 2016 4:07 p.m., "Joe Watkins"

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Dmitry, > "Foo | null" doesn't make sense without "Union Types". I just said that in a chat room, and someone said "I prefer Bar | null over ?Bar, I find myself missing the ?". So maybe there is rationale for choosing a syntax for nullable first, independent of the question of return and

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

"Foo | null" doesn't make sense without "Union Types". Voting for one RFC first makes a preference and unfair. Voting for two different RFCs with 2/3 majority is not good as well. But this is the best option from my point, in case both pass we may make additional voting with simple majority

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

> Am 26.04.2016 um 16:47 schrieb Levi Morrison : > On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov > wrote: >> >> On 04/26/2016 05:19 PM, Bob Weinand wrote: Am 26.04.2016 um 15:33 schrieb Dmitry Stogov

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 8:30 AM, Dmitry Stogov wrote: > > > On 04/26/2016 05:19 PM, Bob Weinand wrote: >>> >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov : >>> >>> hi Levi, >>> >>> It looks like your "work" on "Nullable Types" RFC was intended to win >>> time

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

> Am 26.04.2016 um 16:30 schrieb Dmitry Stogov : > On 04/26/2016 05:19 PM, Bob Weinand wrote: >>> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov : >>> >>> hi Levi, >>> >>> It looks like your "work" on "Nullable Types" RFC was intended to win time >>> for this

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 04/26/2016 05:19 PM, Bob Weinand wrote: Am 26.04.2016 um 15:33 schrieb Dmitry Stogov : hi Levi, It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again. Actually, you have been blocking it for more than a

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-04-26

Results for project PHP master, build date 2016-04-26 06:28:36+03:00 commit: 40b2048 previous commit:434e0fb revision date: 2016-04-25 14:48:36+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Hi Joe, At first, I'm glad this implementation is ready. At least it's possible to analyze its profs and cons. I'm also sure that both RFCs have their opponents and advocates. Now, I just like to make the final voting fair. Thanks. Dmitry. On 04/26/2016 05:13 PM, Joe Watkins wrote: Afternoon

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Dmitry, Just to be clear, the nullable support in the implementation of union/intersection is not a suggestion, the patch will conform to whatever is decided by nullable types RFC. That was always the intention. Cheers Joe On Tue, Apr 26, 2016 at 3:20 PM, Joe Watkins

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Fully agree, I think we should move ahead with the nullable question first, and swiftly. Happy for them to go to vote, tomorrow, if that was serious. Cheers Joe On Tue, Apr 26, 2016 at 3:19 PM, Bob Weinand wrote: > > > Am 26.04.2016 um 15:33 schrieb Dmitry Stogov

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

> Am 26.04.2016 um 15:33 schrieb Dmitry Stogov : > > hi Levi, > > It looks like your "work" on "Nullable Types" RFC was intended to win time > for this patch and block "Nullable Types" again. > Actually, you have been blocking it for more than a year :( > > I'm going to push

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On 04/26/2016 04:57 PM, Levi Morrison wrote: On Tue, Apr 26, 2016 at 7:33 AM, Dmitry Stogov wrote: hi Levi, It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again. Actually, you have been blocking it for

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

Afternoon Dmitry, I started the implementation of this because unions and nullables appears to be in my way (typed properties). At no point did Levi request an implementation. I decided, selfishly, to provide one because it's in my way, and we've been waiting so long already. There

Re: [PHP-DEV] [RFC] Patch for Union and Intersection Types

On Tue, Apr 26, 2016 at 7:33 AM, Dmitry Stogov wrote: > hi Levi, > > It looks like your "work" on "Nullable Types" RFC was intended to win time > for this patch and block "Nullable Types" again. > Actually, you have been blocking it for more than a year :( > > I'm going to push

[PHP-DEV] [RFC] Patch for Union and Intersection Types

hi Levi, It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" again. Actually, you have been blocking it for more than a year :( I'm going to push my own RFC for voting together with "Union Types".

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

Morning Yasuo, > Mm save handler does not compile with ZTS currently. libmm is not intended for use in multi-threaded environments ... mostly because threads don't need to map memory to share, they are already in the same address space. Another problem is processing models. PHP in NTS mode is

[PHP-DEV] Re: [RFC] [Discussion] Octal overflow detection

On 19.04.2016 at 01:24, Sara Golemon wrote: > On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon wrote: >> https://wiki.php.net/rfc/octal.overload-checking >> Because having this expression evaluate to true makes me sad: ("\000" >> === "\400") >> > I haven't heard any responses on

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

Hi all, On Tue, Apr 26, 2016 at 4:44 PM, Remi Collet wrote: > Le 25/04/2016 à 16:09, S.A.N a écrit : >> In userland lacks the ability to store data in the shared memory >> modules, do not use pecl modules, it would be very nice to have a >> function: >> >>

Re: [PHP-DEV] [RFC] IntlCharsetDetector

Hi Sara, On Tue, Apr 12, 2016 at 7:54 AM, Sara Golemon wrote: > With a light push from Stas, I've decided to go ahead and put up > IntlCharsetDetector for discussion. > https://wiki.php.net/rfc/intl.charset-detector > > I'm still not personally convinced this API is trustworthy

Re: [PHP-DEV] [RFC][Discussion] Add session_gc()

Hi Stas, On Tue, Apr 19, 2016 at 3:55 AM, Stanislav Malyshev wrote: >>> Document calling session_gc() periodically is the best practice. >> >> If you want to document usage of this new API as the best practice, it >> would be unfair to the users if you don't also document

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

2016-04-26 11:15 GMT+03:00 Nikita Popov : > As an update here, I plan to create an RFC for bundling the php-ast > extension (maybe with minor modifications) with php-src. This was planned > for 7.1 anyway, and with the annotations RFC under discussion, this seems > like a

Fwd: [PHP-DEV] RFC: Anonymous Class Lexical Scope

Morning internals, Just to be clear, the implementation is now in good shape, the discussion may continue. Attached is message from a confused contributor ... sorry about the confusion :) Cheers Joe -- Forwarded message -- From: Yasuo Ohgaki Date:

Re: [PHP-DEV] Re: [RFC] [Discussion] Octal overflow detection

Hi Sara, On Tue, Apr 19, 2016 at 8:24 AM, Sara Golemon wrote: > On Tue, Apr 12, 2016 at 7:38 PM, Sara Golemon wrote: >> https://wiki.php.net/rfc/octal.overload-checking >> Because having this expression evaluate to true makes me sad: ("\000" >> === "\400") >> >

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

On Tue, Apr 26, 2016 at 9:42 AM, Alexander Lisachenko < lisachenko...@gmail.com> wrote: > Hello, internals! > > I'd like to bring this topic to the discussion again, because now we have > a shiny PHP7 engine and keep moving. PHP grammar becomes more complex and > internal AST representation isn't

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

2016-04-26 10:44 GMT+03:00 Remi Collet : > Le 25/04/2016 à 16:09, S.A.N a écrit : >> In userland lacks the ability to store data in the shared memory >> modules, do not use pecl modules, it would be very nice to have a >> function: >> >> opcache_get($key); >>

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

Le 25/04/2016 à 16:09, S.A.N a écrit : > In userland lacks the ability to store data in the shared memory > modules, do not use pecl modules, it would be very nice to have a > function: > > opcache_get($key); > opcache_set($key, $value); Opcache is an opcode cache. A user data cache is

Re: [PHP-DEV] [RFC][Discussion] Parser extension API

Hello, internals! I'd like to bring this topic to the discussion again, because now we have a shiny PHP7 engine and keep moving. PHP grammar becomes more complex and internal AST representation isn't available for the userland developers, so all static analysis tools suffering from the lack of

Re: [PHP-DEV] [RFC] PHP Attributes

On 04/25/2016 11:20 PM, Stanislav Malyshev wrote: Hi! No, but this is valid: @atrr(); function foo() { ... } That's perhaps a little too close for comfort...? That's different syntax. If you put ; in the middle of statement, it can change - "$c = $a + $b;" is not the same as "$c = $a; +

Re: [PHP-DEV] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

Morning, To answer the question; No, there is no plan to add that. The allocator in opcache is simply not suitable for that kind of use. We could make it suitable, but the optimal allocator for a user cache, and the optimal allocator for a code cache, are different things. IMO they

Re: [PHP-DEV] PHP 7.1 roadmap

On Sun, Apr 24, 2016 at 7:49 PM, Joe Watkins wrote: > Hi Anatol, > > Sounds good to me. > > Cheers > Joe Nice, we are moving forward ! Anyway, Anatol and I are here to help with the tasks. The job is mainly about reviewing code, and above all : organize people and human