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

perform check on each read anyway. Thanks. Dmitry. ________ From: Dmitry Stogov <dmi...@zend.com> Sent: Monday, May 23, 2016 11:30:09 AM To: Joe Watkins; PHP internals; Phil Sturgeon Subject: Re: [PHP-DEV] [RFC][Vote] Typed Properties Hi Joe, The performance

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

Hi Joe, The performance effect of this implementation is terrible. Assignment to typed property is 2.3 times slower. Assignment to untyped property in a class with typed properties is 1.8 times slower. See the benchmark https://gist.github.com/dstogov/1b678712adeee51665cdd829195bb800 Thanks.

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

The patch "corrupts" opcache shared memory. PHP crashes with opcache.protect_memory=1. $ USE_ZEND_ALLOC=0 valgrind sapi/cli/php -d opcache.protect_memory=1 ../Zend/tests/type_declarations/typed_properties_027.php ==900== Memcheck, a memory error detector ==900== Copyright (C) 2002-2015, and GNU

[PHP-DEV] "finally" handling refactoring (Bug #72213)

hi, Please review the path https://gist.github.com/dstogov/0a809891c6a3ac3fac4bd0d9711dd330 I hope, it should completely fix https://bugs.php.net/bug.php?id=72213 I'm going to commit this on Monday. Thanks. Dmitry.

Re: [PHP-DEV] [RFC][VOTE] Closure from callable

I'm sorry, I didn't follow the RFC discussion. In general I like the idea, but why not to use Closure constructor? $f = new Closure("some_func"); would look more readable than $f = Closure::fromCallable("some_func"); Sorry, if this was already discussed before. Thanks. Dmitry.

[PHP-DEV] Single Stack for all generators

Hi, Nikita, please review the patch https://gist.github.com/dstogov/06116f1610f45f8152ine3a9927c6c243ac It's the next attempt to use the single stack for all generators. Now I don't see any problems or BC breaks. In case "yield" is used as an expression in context of function call. e.g.

[PHP-DEV] outRe: [PHP-DEV] [RFC] [VOTE] PHP Attributes

mar in attribute strings, we would just provide an API call in the engine that reuses zendparse() and returns AST. This would take just 10-20 C lines. Thanks. Dmitry. Cheers Joe On Wed, May 11, 2016 at 8:11 AM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote:

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

On 05/11/2016 10:27 AM, Stanislav Malyshev wrote: Hi! Personally, I'm for AST as well, but it's possible to get the same power translating string values of attributes into AST in the hooks. Extending this, it's also possible to get the same power just extracting phpdocs and applying AST to

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

d extract the necessary part of meta information every time you need it. It's not a big problem to do this using Doctrine library, but how are you going to do this in a compiler hook? Cheers Joe On Wed, May 11, 2016 at 7:45 AM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wr

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

ler; Anything else is not good enough. Personally, I'm for AST as well, but it's possible to get the same power translating string values of attributes into AST in the hooks. Thanks. Dmitry. Cheers Joe On Wed, May 11, 2016 at 6:26 AM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...

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

<pthre...@pthreads.org> Sent: Wednesday, May 11, 2016 7:46:09 AM To: Björn Larsson Cc: Dmitry Stogov; PHP internals Subject: Re: [PHP-DEV] [RFC] [VOTE] PHP Attributes Morning Dmitry, I'm not really happy with the voting options here. I would not vote in favour of a patch that does not i

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

On 05/11/2016 12:29 AM, Björn Larsson wrote: Den 2016-05-10 kl. 20:29, skrev Dmitry Stogov: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart tool for PHP extension

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

On 05/10/2016 11:48 PM, Benjamin Eberlei wrote: On Tue, May 10, 2016 at 8:29 PM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes

[PHP-DEV] [RFC] [VOTE] PHP Attributes

Hi internals, I've started voting on "PHP Attributes" RFC. https://wiki.php.net/rfc/attributes In my opinion, "PHP Attributes" might be a smart tool for PHP extension, but it's not going to be the end of the world, if we decided to live with doc-comments only. Thanks. Dmitry.

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 05/06/2016 05:06 AM, Jesse Schalken wrote: If you're going to say "do what you want" with regards to annotations, then just let them be a text string. Parsing the annotation as PHP but not evaluating it as PHP seems a very strange and arbitrary half-way point. If the thing consuming the AST

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 05/05/2016 10:24 AM, Alexander Lisachenko wrote: Hello, internals! 2016-05-05 9:48 GMT+03:00 Stanislav Malyshev >: Maybe that's what we want to have here - freedom for everybody to invent their own languages - but I fear the

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 05/05/2016 09:48 AM, Stanislav Malyshev wrote: Hi! It's also possible to write: <> you don't need to split your annotation into many attributes. You should just adopt its

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 05/01/2016 10:47 PM, Larry Garfield wrote: On 04/30/2016 06:21 PM, Rowan Collins wrote: On 30/04/2016 23:45, Stanislav Malyshev wrote: Oh, of course you can have methods, but then it is strange conceptually - you have a normal class, which some other part of the language just uses for

Re: [PHP-DEV] Attributes/Annotations Case Study: Drupal

On 04/30/2016 02:47 AM, Larry Garfield wrote: Most of the examples that have been given so far are either trivial boolean flags or data validation rules to be evaled. In practice, very little of Drupal's use of annotations in Drupal 8 fit either category. Rather, they're used primarily as,

Re: [PHP-DEV] zend_pass_function/zif_pass

I don't see a big problem exporting zif_pass, if this's really necessary. Thanks. Dmitry. From: Nikita Popov <nikita@gmail.com> Sent: Saturday, April 30, 2016 8:40:54 PM To: Derick Rethans Cc: Dmitry Stogov; PHP Developers Mailing List Subject: Re: [P

Re: [PHP-DEV] Forbid dynamic calls to scope introspection/modification functions

Hi Nikita, We already discussed this, and I told that I don't have strong opinion about this change. >From one pint of view, your are going to disable some legal code patterns. function foo() { $f = "func_num_args"; $n = $f(); } array_map("export", [$_GET, $_POST]); On the other hand,

[PHP-DEV] Re: New HashTable implementation?

. From: Matt Wilmas <php_li...@realplain.com> Sent: Friday, April 29, 2016 3:04:44 AM To: internals@lists.php.net Cc: Dmitry Stogov; Nikita Popov; Xinchen Hui Subject: New HashTable implementation? Hi all, Last June, it was briefly mentioned about ch

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

More or less right. It's easy to archive the "right" goal, if you own the both football teams. From: Tom Worster <f...@thefsb.org> Sent: Thursday, April 28, 2016 11:40:53 PM To: Levi Morrison; Dmitry Stogov Cc: internals Subject: Re: [PHP-

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

;Nullable Types" RFC was accepted now, but I don't trust in your intention to support it. From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi Morrison <le...@php.net> Sent: Thursday, April 28, 2016 10:02:20 PM T

Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

net> Sent: Thursday, April 28, 2016 9:47:18 PM To: Joe Watkins Cc: Dmitry Stogov; internals; Tom Worster Subject: Re: [PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values On Thu, Apr 28, 2016 at 11:55 AM, Joe Watkins <pthre...@pthreads.org> wrote: > Levi,

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

PHP method compatibility rules didn't take into account default values of arguments. Adding new rule is not just a bug fix, and breaks existing code. From: Bob Weinand <bobw...@hotmail.com> Sent: Thursday, April 28, 2016 9:12:54 PM To: Dmitry Sto

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

ursday, April 28, 2016 8:36:22 PM To: Dmitry Stogov Cc: Anatol Belski; Joe Watkins; internals; Levi Morrison Subject: Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values > Am 28.04.2016 um 18:28 schrieb Dmitry Stogov <dmi...@zend.com>: > > Hi, > > T

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

ril 28, 2016 8:47:41 PM To: Dmitry Stogov Cc: internals; Tom Worster Subject: Re: Request to withdraw RFC's for nullable types for only return values On Thu, Apr 28, 2016 at 11:43 AM, Dmitry Stogov <dmi...@zend.com> wrote: > your Nullable RFC doesn't propose w

Re: [PHP-DEV] Request to withdraw RFC's for nullable types for only return values

all these are good points not to commit BC breaks in hurry. From: Joe Watkins <pthre...@pthreads.org> Sent: Thursday, April 28, 2016 8:41:34 PM To: Bob Weinand Cc: Dmitry Stogov; Anatol Belski; internals; Levi Morrison Subject: Re: [PHP-DEV] Request to wi

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

your Nullable RFC doesn't propose working implementation. From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi Morrison <le...@php.net> Sent: Thursday, April 28, 2016 8:39:03 PM To: Dmitry Stogov Cc: internals; Tom Worster

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

. Thanks. Dmitry. From: Joe Watkins <pthre...@pthreads.org> Sent: Thursday, April 28, 2016 8:20:12 PM To: Dmitry Stogov Cc: Levi Morrison; internals; Tom Worster Subject: Re: Request to withdraw RFC's for nullable types for only return values Evening

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

internals Cc: Dmitry Stogov; Tom Worster Subject: Request to withdraw RFC's for nullable types for only return values I have discovered through a [bug report][1] a case where having explicitly nullable parameters would be of value. You can theoretically change the default value i

[PHP-DEV] Re: Request to withdraw RFC's for nullable types for only return values

revert this before 7.0.6 release. Thanks. Dmitry. From: morrison.l...@gmail.com <morrison.l...@gmail.com> on behalf of Levi Morrison <le...@php.net> Sent: Thursday, April 28, 2016 18:40 To: internals Cc: Dmitry Stogov; Tom Worster Subject: Request

[PHP-DEV] Re: Request for Karma

, 2016 20:34 To: php-internals Cc: Dmitry Stogov Subject: Request for Karma Hello fellows! I would like to request karma for the PHP wiki to support others in writing RFCs and maybe some time in the future contribute RFCs. For now I plan to help Dmitry Stogov as co-author with the already ex

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

On 04/27/2016 08:25 AM, Pierrick Charron wrote: 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

[PHP-DEV] Re: Property Guards Optimization

great. thanks. From: Nikita Popov <nikita@gmail.com> 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 <dmi...@zend.com<mailto:dmi

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

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

Just because HHVM is closer to PHP than C#. From: Dominic Grostate <codekest...@googlemail.com> 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

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

with simple majority "Union" or "Nullable" or "Union+Nullable". Thanks. Dmitry. From: Levi Morrison <morrison.l...@gmail.com> Sent: Tuesday, April 26, 2016 17:47 To: Dmitry Stogov Cc: Bob Weinand; internals; Joe Watkins Subje

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 <dmi...@zend.com>: 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

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

. There is no conspiracy. I would actually like it if nullable types came first, I would have preferred not to have my work on typed properties stopped also. We don't always get what we want :) Cheers Joe On Tue, Apr 26, 2016 at 2:33 PM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@ze

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 <dmi...@zend.com> wrote: hi Levi, It looks like your "work" on "Nullable Types" RFC was intended to win time for this patch and block "Nullable Types" aga

[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] [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] [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 <guilhermebla...@gmail.com> Sent: Monday, April 25, 2016 17:22 To: Dmitry

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 <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: On 04/22/2016 06:39 PM, guilhermebla...@gmail.com <mailto:guilhermebla...@gmail.com> wrote: On Fri,

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

something anyway. Thanks. Dmitry. Cheers Joe PS. If anyone is interested http://github.com/krakjoe/dbc was my first attempt at interacting with the patch. On Mon, Apr 25, 2016 at 11:08 AM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: On 04/25/2016 1

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

but other commented on it so I won't interfer here :). I've collected the most interesting feedback at https://wiki.php.net/rfc/attributes#open_issues And I'm going to correct RFC and implementation rethinking these questions. Thanks. Dmitry. On Mon, Apr 25, 2016 at 3:17 PM, Dmitry Stogov <

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

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

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 <dmi...@zend.com> 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 cri

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 <dmi...@zend.com> 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 e

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 <dmi...@zend.com> wrote: 3- Did you put any thought on inheritance? What I mentioned in comment #1 is even smaller than what you imple

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 <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: On 04/22/2016 04:05 AM, guilhermebla...@gmail.com <mailto:guilhermebla...@gmail.com> wrote: Hi Dmitry,

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

On 04/22/2016 02:46 PM, Thomas Punt wrote: Hi Dmitry! Hi, 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 same. The most interesting difference is an ability to use arbitrary

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

ot;Entity"]=> bool(true) } <<ORM\Entity>> - doesn't work now, but I'll implement this and extend RFC on next week. Thanks. Dmitry. From: Dominic Grostate <codekest...@googlemail.com> Sent: Friday, April 22, 2016 11:31 To: Dmitry Stogo

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

On 04/22/2016 05:15 AM, Sara Golemon wrote: On Thu, Apr 21, 2016 at 2:13 PM, Dmitry Stogov <dmi...@zend.com> wrote: I would like to present an RFC proposing support for native annotation. I'm trying to imagine where the benefit of non-constant expressions comes in. <&l

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

icient) Thanks. Dmitry. Regards, On Thu, Apr 21, 2016 at 7:44 PM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: On 04/22/2016 02:16 AM, Dominic Grostate wrote: This is amazing. It would actually allow us to implement our automated ass

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

e will get at the end. Thanks. Dmitry. On 21 Apr 2016 10:13 p.m., "Dmitry Stogov" <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavior are mostly i

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

On 04/22/2016 02:09 AM, Colin O'Dell wrote: > A more robust alternative would be something along the same lines that > Doctrine uses: Make annotations actual classes. Just spitballing here - what if both approaches were supported, but class-based annotations were prefixed with a special

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

On 04/22/2016 02:02 AM, Ryan Pallas wrote: On Thu, Apr 21, 2016 at 4:51 PM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: About expressions, isn't there an ambigoutiy? <<test(1)>> is a "plain" name, value

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

On 04/22/2016 01:03 AM, Benjamin Eberlei wrote: On Thu, Apr 21, 2016 at 11:13 PM, Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>> wrote: Hi, I would like to present an RFC proposing support for native annotation. The naming, syntax and behavio

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

On 04/22/2016 12:52 AM, Larry Garfield wrote: On 4/21/16 4:13 PM, Dmitry Stogov wrote: Hi, 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 same. The most interesting

[PHP-DEV] [RFC] PHP Attributes

Hi, 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 same. The most interesting difference is an ability to use arbitrary PHP expressions as attribute values. These expressions are

Re: [PHP-DEV] Safe timeout handling

On 04/20/2016 08:40 PM, Bob Weinand wrote: Am 20.04.2016 um 18:22 schrieb Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>>: On 04/20/2016 06:24 PM, Matt Wilmas wrote: Hi Dmitry, - Original Message - From: "Dmitry Stogov" Sent: Wednesday, April

Re: [PHP-DEV] Safe timeout handling

On 04/20/2016 06:24 PM, Matt Wilmas wrote: Hi Dmitry, - Original Message - From: "Dmitry Stogov" Sent: Wednesday, April 20, 2016 Hi, It's a well known PHP problem, that exceeding of execution time-out (max_execution_time) may lead to unexpected crashes. They occur becau

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

o may make sense. Someone may like this, someone not. Thanks. Dmitry. From: guilhermebla...@gmail.com <guilhermebla...@gmail.com> Sent: Wednesday, April 20, 2016 18:05 To: Lin Yo-An Cc: Dmitry Stogov; Tom Worster; internals Subject: Re: [PHP-DEV] [RFC] Nullab

[PHP-DEV] Safe timeout handling

Hi, It's a well known PHP problem, that exceeding of execution time-out (max_execution_time) may lead to unexpected crashes. They occur because PHP may be interrupted in inconsistent state, and attempt to release allocated by request resources leads to failure. Almost any big site sees these

Re: [PHP-DEV] Re: Typed properties patch

On 04/19/2016 10:53 PM, Stanislav Malyshev wrote: Hi! More properly - PHP is done in a way that doesn't allow big data processing yet :) LuaJIT may be used for in-kernel packet filtering... But we're not targeting PHP for in-kernel packet filtering. And we should not sacrifice language

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

It should be possible to do this for functions and simple classes. Most probably this will require some engine changes, but this is not a big problem for major release. Conditional definition and run-time class inheritance will make significant troubles. Thanks. Dmitry.

Re: [PHP-DEV] RFC: Functional Interfaces

On 04/19/2016 05:30 PM, Rowan Collins wrote: Dmitry Stogov wrote on 19/04/2016 15:12: I prefer intuitive concepts, that I may use without rereading manual again and again. For this one, I even can't imagine a natural (not over-designed) use case. The use case that came to my mind is kind

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

On 04/19/2016 05:18 PM, Nikita Popov wrote: On Tue, Apr 19, 2016 at 3:31 PM, Joe Watkins wrote: Morning Internals, Please review the following RFC: https://wiki.php.net/rfc/lexical-anon A look at the patch from those of you that do that would be good

Re: [PHP-DEV] RFC: Functional Interfaces

ous. But also ... > I thought the same might be implemented through anonymous classes. An anonymous class cannot be rebound, they are obviously not the same thing. > I didn't take a deep look into the code. I'll wait until you have, I think :) Cheers Joe On Tue, Apr 19, 2016 at 2:22 PM, Dmit

Re: [PHP-DEV] RFC: Functional Interfaces

xecute_data *interface in zend_closure structure. I thought the same might be implemented through anonymous classes. Thanks. Dmitry. > zend_do_inheritance_ex(type, zend_ce_closure, 1); > zend_class_implements(type, 1, interface); Cheers Joe On Tue, Apr 19, 2016 at

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

On 04/19/2016 04:09 PM, Levi Morrison wrote: On Tue, Apr 19, 2016 at 6:39 AM, Dmitry Stogov <dmi...@zend.com> wrote: Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The res

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

Only one note. I would prefer to use "," instead of "|" as a class name separator. Especially if "Union types" are not accepted. The rest should be fine. Thanks. Dmitry. From: Bronisław Białek Sent: Sunday, April 17, 2016 19:51 To:

Re: [PHP-DEV] RFC: Functional Interfaces

Are $cb1 and $cb2 going to be the same (do the same)? Is this just a new syntax sugar, or a really new feature? According to implementation, I think, you shouldn't extend "zend_closure" with "interface". If this is a sugar, lets implement it as a sugar (without VM changes). But may be I

Re: [PHP-DEV] Re: Typed properties patch

On 04/18/2016 09:37 PM, Stanislav Malyshev wrote: Hi! right. I don't see any reasons for types, if they are not guaranteed anyway. Well, we already have parameter types, and they are not guaranteed either - you can reassign variables. They guarantee the type of argument on function entry.

Re: [PHP-DEV] Re: Typed properties patch

On 04/15/2016 11:07 PM, Stanislav Malyshev wrote: Hi! In most cases we avoid IS_UNDEF checks, verifying the most probable expected types first. But that's for something like ADD, not for property fetches, so I'm not sure I understand how properties fit there yet. Does the optimization also

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

The grammar is taken from HHVM. Using any other would make more mess. Thanks. Dmitry. From: Tom Worster <f...@thefsb.org> Sent: Saturday, April 16, 2016 04:54 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/15/16 1

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

intersections. Thanks. Dmitry. From: Tom Worster <f...@thefsb.org> Sent: Friday, April 15, 2016 20:17 To: Dmitry Stogov; internals Subject: Re: [PHP-DEV] [RFC] Nullable Types On 4/14/16 3:50 AM, Dmitry Stogov wrote: > The up to date imple

Re: [PHP-DEV] Re: Typed properties patch

___ From: Stanislav Malyshev <smalys...@gmail.com> Sent: Thursday, April 14, 2016 20:26 To: Dmitry Stogov; Joe Watkins Cc: internals; Zeev Suraski; Nikita Popov Subject: Re: [PHP-DEV] Re: Typed properties patch Hi! > I didn't understand. > Of course we keep a class definition,

Re: [PHP-DEV] Re: Typed properties patch

On 04/13/2016 10:31 PM, Stanislav Malyshev wrote: Hi! Because if you unset() a property it's type is not guaranteed anymore. Can't we fix it? I mean, when we unset property on an object, we're still keeping the definition in the class, right? Can't we use it? I didn't understand. Of course

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

The RFC doesn't say anything about support for multiple class names. function foo(A|B|C $x) Support for multiple classes would lead to complex implementation. Thanks. Dmitry. From: Levi Morrison Sent: Thursday, April 14, 2016

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

On 04/14/2016 06:42 AM, Levi Morrison wrote: As alluded to in an earlier email today[1] I am now moving the Nullable Types RFC[2] to the discussion phase. In a nutshell this RFC proposes syntax for declaring a type to alternatively be null. +1 The up to date implementation for

Re: [PHP-DEV] Re: Typed properties patch

We are talking only about unsettling of typed properties From: guilhermebla...@gmail.com <guilhermebla...@gmail.com> Sent: Wednesday, April 13, 2016 16:08 To: Dmitry Stogov Cc: Nikita Popov; Stanislav Malyshev; internals; Joe Watkins; Zeev Suraski Subje

Re: [PHP-DEV] Re: Typed properties patch

On 04/13/2016 07:33 AM, Stanislav Malyshev wrote: Hi! Thanks for your time reviewing the patch, appreciated. > 1) nullable properties I agree that we need a way to that, but I would rather see it covered by nullable types rfc. I think this is an attempt to achieve more type

[PHP-DEV] Re: Object getter method optimization

I think, It's going to be a part of opcache. Today, all PHP processes use shared bytecode, with JIT we will in addition share the native code. Thanks. Dmitry. From: Lin Yo-An <cornelius.h...@gmail.com> Sent: Monday, April 11, 2016 19:04 To: Dmitry Sto

[PHP-DEV] Re: Object getter method optimization

Hi Yo-An On 04/11/2016 02:54 PM, Lin Yo-An wrote: Hi Dmitry, How's it going? I traversed the code of opcache extension, and just found the FUNC_INFO related macros. I guess the accessor information is more like an entry that should be put in the function info. That, FUNC_INFO is

Re: [PHP-DEV] Typed properties patch

On 04/07/2016 08:55 PM, Fleshgrinder wrote: On 4/7/2016 3:55 PM, Dmitry Stogov wrote: On 04/07/2016 03:44 PM, Bob Weinand wrote: Am 6.4.2016 um 10:45 schrieb Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>>: 1) While parameters allow null to be accepted as the default

Re: [PHP-DEV] Typed properties patch

On 04/07/2016 03:44 PM, Bob Weinand wrote: Hey, Am 6.4.2016 um 10:45 schrieb Dmitry Stogov <dmi...@zend.com <mailto:dmi...@zend.com>>: Hi Jow, First of all, I appreciate the amount of effort you already invested into this idea. Anyway, I still don't agree with the fol

[PHP-DEV] Re: Typed properties patch

________ From: Dmitry Stogov Sent: Wednesday, April 6, 2016 10:32 To: Joe Watkins Subject: Typed properties patch Ho Joe, I see some tests failures (SIGSEGV) > Test typed properties float widen at runtime > [Zend/tests/type_declarations/typed_properties_027.phpt] &

[PHP-DEV] Re: Object getter method optimization

see a big reason to do it. Thanks. Dmitry. From: Lin Yo-An <cornelius.h...@gmail.com> Sent: Tuesday, April 5, 2016 17:32 To: Dmitry Stogov Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals Subject: Re: Object getter method optimization On

[PHP-DEV] Re: Object getter method optimization

next week. Thanks. Dmitry. From: Lin Yo-An <cornelius.h...@gmail.com> Sent: Tuesday, April 5, 2016 17:00 To: Dmitry Stogov Cc: Xinchen Hui; Nikita Popov; Bob Weinand; Joe Watkins; internals Subject: Re: Object getter method optimization Hi Dmitry, Glad to he

Re: [PHP-DEV] RETURN micro optimization

On 04/05/2016 12:04 PM, Derick Rethans wrote: On Tue, 5 Apr 2016, Dmitry Stogov wrote: I propose a micro optimization for RETURN statement. Currently "return $x" increments reference counter of $x, then in zend_leave_helper() we perform zval_ptr_dtor() on the same $x. The

<    1   2   3   4   5   6   7   8   9   10   >