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

Hey: On Mon, Apr 25, 2016 at 10:09 PM, S.A.N wrote: > 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); > > Is planned in

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

Internals, Joe Watkins and Bob Weinand have worked out a [proof-of-concept patch for union types][1]. Please go download it and experiment with it. A few things to note: * This patch includes intersection types. However, a type expression must be either a union type or an intersection type;

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

> Meanwhile, you haven't addressed the point being made as a reason not to > bundle, which is that this is not a universally-useful solution, and there > needs to be some reason why this needs to be incorporated - under whatever > name - any more urgently than a memcache driver, or a redis driver,

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

On 4/25/2016 10:04 PM, Rowan Collins wrote: > On 25/04/2016 19:37, Stanislav Malyshev wrote: >> Hi! >> >>> @attr() - is a valid "silenced" call to function named "attr". >>> This syntax can't be reused. >> Not valid if it's in the middle of class definition, and not valid in >> form of: >> >>

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

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; + $b;" - but nobody thinks + can not be used

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

On 25/04/2016 19:07, S.A.N wrote: I am not against third-party libraries, I want to have this functionality out of the box, it seems to me correct to make these functions in OPCache, instead of adding Apcu to PHP core, IMHO... Literally the only difference between including APCu in core and

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

On Mon, 25 Apr 2016, 21:07 S.A.N, wrote: > 2016-04-25 20:56 GMT+03:00 Rowan Collins : > > S.A.N wrote on 25/04/2016 18:49: > >>> > >>> There's not really a huge connection between opcode caching and > >>> optimization > >>> >(OpCache) and shared

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

On 25/04/2016 19:37, Stanislav Malyshev wrote: Hi! @attr() - is a valid "silenced" call to function named "attr". This syntax can't be reused. Not valid if it's in the middle of class definition, and not valid in form of: @attr() function foo() { ... } This is not a valid PHP syntax now. So

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

Check here to see what we did for php-annotations: https://github.com/php-annotations/php-annotations/blob/master/docs/CustomAnnotations.rst#usageannotation It's somewhat similar to how C# does it, and it has worked quite nicely. On Mon, Apr 25, 2016 at 8:40 PM, Stanislav Malyshev

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

On 25/04/16 19:07, S.A.N wrote: > I am not against third-party libraries, I want to have this > functionality out of the box, it seems to me correct to make these > functions in OPCache, instead of adding Apcu to PHP core, IMHO... So how do you then manage the data when the PHP servers are

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

Hi! > a class/property/method that has annotations, it NOT inherit > annotations/attributes by default. However, by adding an annotation of > > <<__inherit>> > > (Or some other internal-reserved keyword, I don't have strong feelings > on what it is) then the engine will automatically give you

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

Hi! > @attr() - is a valid "silenced" call to function named "attr". > This syntax can't be reused. Not valid if it's in the middle of class definition, and not valid in form of: @attr() function foo() { ... } This is not a valid PHP syntax now. So I'm not sure why it can't be used. << is an

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

Hi! > The proposed by you "@..." syntax just won't fit into PHP grammar, > because @ used as silence operator. Not sure why it is a problem more than << and >> being shift operators. Since you said it can't be applied to anonymous functions/classes anyway, parser with the help of AST should be

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

On 25 April 2016 at 20:07, S.A.N wrote: > 2016-04-25 20:56 GMT+03:00 Rowan Collins : > > S.A.N wrote on 25/04/2016 18:49: > >>> > >>> There's not really a huge connection between opcode caching and > >>> optimization > >>> >(OpCache) and shared

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

2016-04-25 20:56 GMT+03:00 Rowan Collins : > S.A.N wrote on 25/04/2016 18:49: >>> >>> There's not really a huge connection between opcode caching and >>> optimization >>> >(OpCache) and shared memory data caches (APCu, memcached, etc), so I >>> > don't >>> >think there's

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

S.A.N wrote on 25/04/2016 18:49: There's not really a huge connection between opcode caching and optimization >(OpCache) and shared memory data caches (APCu, memcached, etc), so I don't >think there's any particular logic to calling such functions "opcache". > >So I guess the question becomes:

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

This seems to mix the concerns of an opcode cache (saves opcodes) with a user-cache (saves mixed data). You should just use APCu for that. Marco Pivetta http://twitter.com/Ocramius http://ocramius.github.com/ On 25 April 2016 at 19:49, S.A.N wrote: > 2016-04-25 17:36

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

2016-04-25 17:36 GMT+03:00 Rowan Collins : > S.A.N wrote on 25/04/2016 15:09: >> >> 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] [RFC] PHP Attributes

On Mon, Apr 25, 2016 at 7:11 PM, Rowan Collins wrote: > guilhermebla...@gmail.com wrote on 25/04/2016 15:22: > >> Another thing that looks odd to me i that every time you call new >> ReflectionClass, a new reflection_object gets created. >> Isn't there a way to get this

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

guilhermebla...@gmail.com wrote on 25/04/2016 15:22: Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? I recently came upon a package that exists solely to

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

André Rømcke wrote on 25/04/2016 18:00: >So I guess the question becomes: "should APCu be made part of core?" I'm not aware of anyone having proposed that, so don't know if there are strong feelings for or against such a thing. As long as it’s cache is not shared among processes, rather not.

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

On Mon, Apr 25, 2016 at 6:49 PM, Larry Garfield wrote: > On 04/25/2016 10:20 AM, Dmitry Stogov wrote: > >> >> This leads to some serious copy/paste, highly error prone... =( >>> >> >> If we had a theoretical approach for attribute inheritance, I would >> implement it. >>

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

> On 25 Apr 2016, at 16:36 , Rowan Collins wrote: > > S.A.N wrote on 25/04/2016 15:09: >> 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] [RFC] PHP Attributes

On 04/25/2016 10:20 AM, Dmitry Stogov wrote: This leads to some serious copy/paste, highly error prone... =( If we had a theoretical approach for attribute inheritance, I would implement it. But I wouldn't invite any theory, because anyone is going to depend on use-case. Realistically, I

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

> I really don't like 'as' in this context, even if Hack uses it, as it > doesn't reflect in English terms what the code is doing. As others > have already said, it reads as if 'T' is being aliased to 'Bar'. I second that. I hear the concerns about adding another reserved word "is" though, so

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

This is another reason to use PHP layer on top on base attribute functionality. Implementing caching would take just 3 additional lines of PHP code. From: guilhermebla...@gmail.com Sent: Monday, April 25, 2016 17:22 To: Dmitry Stogov

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

On 04/25/2016 05:11 PM, guilhermebla...@gmail.com wrote: On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov > wrote: On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-04-25

Results for project PHP master, build date 2016-04-25 06:28:35+03:00 commit: 434e0fb previous commit:304e5ae revision date: 2016-04-24 21:46:20+02: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] Opcache::get($key), set($key, $value) to shared memory, is planned in PHP 7.1?

S.A.N wrote on 25/04/2016 15:09: 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); Is planned in PHP 7.1? This was identified as a difference between APC

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

Another thing that looks odd to me i that every time you call new ReflectionClass, a new reflection_object gets created. Isn't there a way to get this "cached" somehow in zend_class_entry? On Mon, Apr 25, 2016 at 10:11 AM, guilhermebla...@gmail.com < guilhermebla...@gmail.com> wrote: > > > On

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

On Mon, Apr 25, 2016 at 3:42 AM, Dmitry Stogov wrote: > > > On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: > > > On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: > >> >> >> On 04/22/2016 04:05 AM, >>

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

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); Is planned in PHP 7.1? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

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

Dan Ackroyd wrote on 24/04/2016 21:45: The point I was trying to make is that it explicitly says that "this is a userland attribute", rather than using the generic <<...>> syntax, which we might want to use for non-userland attributes at some point. I think framing the problem as "engine vs

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

On 04/25/2016 02:28 PM, Joe Watkins wrote: Morning internals, This morning I attempted to prototype a dbc extension. In my opinion, the patch, or internals, are not fit for the intended purpose. At the moment, the *only* way to perform meta programming is going to be in

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

On 25/04/16 09:42, Dmitry Stogov wrote: > I know, any syntax is going to be loved by ones and hated by others... > It's not possible to satisfy everyone. If one takes a step back, current well used annotation IS provided but not cleanly documented in the docbloc material that is a major element

Re: [PHP-DEV] Re: ext/curl update

On Sun, 24 Apr 2016 at 01:25 Davey Shafik wrote: > Hi Pierrick, > > This should be in master for 7.1, alongside my RFC'ed patch for server push > support. I don't see why the additional constants that don't have a direct dependency on your server push patch can't be committed to

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

Forwarded, sorry for top post :( -- Forwarded message -- From: Joe Watkins Date: Mon, Apr 25, 2016 at 12:28 PM Subject: Re: [PHP-DEV] [RFC] PHP Attributes To: Dmitry Stogov Cc: Pierre Joye , PHP internals <

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

Morning internals, This morning I attempted to prototype a dbc extension. In my opinion, the patch, or internals, are not fit for the intended purpose. At the moment, the *only* way to perform meta programming is going to be in userland. This is going to make it prohibitively slow,

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

On 04/25/2016 12:44 PM, Pierre Joye wrote: hi Dmitry, Awesome work! Thanks. I do like you keep what was discussed last time. Make the basics available and leave the rest to the applications (doctrine or other). I feel too that how the apps will interact with may need some more discussions

Re: [PHP-DEV] [VOTE] Catching Multiple Exception Types

Patrick ALLAERT wrote on 24/04/2016 14:18: There is just nothing more repeatable or common cases than "resource not found", "method not allowed", "access denied",... They are all non exceptional cases better handled without exceptions and with clean APIs reflecting the business logic of the

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

hi Dmitry, Awesome work! Thanks. I do like you keep what was discussed last time. Make the basics available and leave the rest to the applications (doctrine or other). I feel too that how the apps will interact with may need some more discussions but other commented on it so I won't interfer

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

On 04/24/2016 02:09 AM, Thomas Bley wrote: The <<>> syntax comes with the problem that previous versions cannot ignore it on parsing. So poeple write new frameworks for 7.0 which cannot be parsed in 5.x, then they write new frameworks for 7.1 which cannot be parsed with 7.0 and 5.x and so

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

On 04/25/2016 06:23 AM, Stanislav Malyshev wrote: Hi! https://wiki.php.net/rfc/attributes I've read the proposal and I like the idea of reviving the attributes idea and the simplicity of the approach. I have the following questions for it: - Namespacing. Since the attribute names are not

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

> > I think that the Hack name attributes is unintelligible and annotations >> would be much clearer to any audience. Simply because the name is very >> well known. >> > > Different languages names this differently. > I may add an additional voting question - "annotation vs attributes?". The

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

On 04/24/2016 07:57 PM, Levi Morrison wrote: On Sun, Apr 24, 2016 at 10:03 AM, Dan Ackroyd wrote: On 21 April 2016 at 22:13, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. Hi Dmitry, Although

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

On 04/24/2016 07:03 PM, Dan Ackroyd wrote: On 21 April 2016 at 22:13, Dmitry Stogov wrote: Hi, I would like to present an RFC proposing support for native annotation. Hi Dmitry, Although everyone will have an opinion about the syntax, I think there is one criticism that

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

On 04/24/2016 12:34 AM, Yasuo Ohgaki wrote: Hi Dimitry, On Fri, Apr 22, 2016 at 6:13 AM, Dmitry Stogov wrote: I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly influenced by HHVM Hack, but not exactly the

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

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 think that the Hack name attributes is unintelligible and

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

On 04/24/2016 05:02 PM, Thomas Punt wrote: Hi! From: dmi...@zend.com On 04/22/2016 02:46 PM, Thomas Punt wrote: Hi Dmitry! Just a couple of comments on this: 1. I'd definitely reuse the php-ast extension for parsing the code into an AST. It performs a number of transformations on PHP's

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

On 04/24/2016 03:33 PM, Fleshgrinder wrote: I am not arguing against the RFC nor the feature itself, on the contrary, I like it. I just do not like certain aspects and design decisions of it; that is all. Configuration and AOP are the best usecases for annotations and those should be stressed

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

On 04/24/2016 11:24 AM, Fleshgrinder wrote: The invariant could also be added as an additional branch to the class instead of a method, since it would not work like a method. class A {} invariant {} function f() {} require {} ensure {} This would also align nicely with closures and

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

On 04/22/2016 06:56 PM, Larry Garfield wrote: On 4/22/16 10:39 AM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov wrote: 3- Did you put any thought on inheritance? What I mentioned in comment #1 is even smaller than what you implemented

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

On 04/22/2016 06:39 PM, guilhermebla...@gmail.com wrote: On Fri, Apr 22, 2016 at 3:07 AM, Dmitry Stogov > wrote: On 04/22/2016 04:05 AM, guilhermebla...@gmail.com wrote: Hi Dmitry, As a previous

RE: [PHP-DEV] Lazy keys comparison during hash lookups

> -Original Message- > From: Andone, Bogdan [mailto:bogdan.and...@intel.com] > Sent: Friday, March 18, 2016 11:58 AM > To: 'Nikita Popov' > Cc: internals@lists.php.net > Subject: RE: [PHP-DEV] Lazy keys comparison during hash lookups > > > -Original

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

On Sun, Apr 24, 2016 at 2:58 AM, Levi Morrison wrote: > On Sat, Apr 23, 2016 at 10:40 AM, Quim Calpe wrote: > > Option is no better than a union type with null[1]. If a language > requires an option to be unwrapped then it can do the same with some > type or null.