Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 05/24/2016 05:29 AM, Xinchen Hui wrote: Hey: On Tue, May 24, 2016 at 4:24 AM, Dmitry Stogov > wrote: Hi internals, Please review the RFC. It proposes to fix all known inconsistencies related to handling of special $this variable. in section st

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 05/24/2016 08:45 AM, Jesse Schalken wrote: I'm curious, what is it about $this that makes it special in the first place? Can't it be a normal local variable that happens to already be assigned at the start of a method? In fact $this is not a regular local variable and it must not be re-a

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On Tue, May 24, 2016 at 5:18 PM, Dmitry Stogov wrote: > In fact $this is not a regular local variable and it must not be > re-assigned. > > You're just restating the premise for my question. Why is it not a regular local variable? Why must it not be reassigned?

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 05/24/2016 09:54 AM, Stanislav Malyshev wrote: Hi! Please review the RFC. It proposes to fix all known inconsistencies related to handling of special $this variable. https://wiki.php.net/rfc/this_var What is the reason behind all these changes? Does it serve some bigger purpose? I star

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

Ok. One more attempt with both tests fixed. https://github.com/php/php-src/pull/1919 Nikita, you may take a look only into the last commit. Do you see any other problems? Sorry for abusing your time, but your feedback is extremely useful. Thanks. Dmitry. Thanks. Dmitry. __

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

Jesse, On Tue, May 24, 2016 at 4:25 PM, Jesse Schalken wrote: > On Tue, May 24, 2016 at 5:18 PM, Dmitry Stogov wrote: > >> In fact $this is not a regular local variable and it must not be >> re-assigned. >> >> > You're just restating the premise for my question. Why is it not a regular > local v

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

Hi! > Keeping inconsistent behavior isn't good as well. It's not good, but it's not also very bad. Nobody really does that, so whatever happens in these cases is mostly irrelevant. Did you test performance impact of those changes? > Actually, $this may be assigned to local variable in run-time

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 05/24/2016 11:04 AM, Stanislav Malyshev wrote: Hi! Keeping inconsistent behavior isn't good as well. It's not good, but it's not also very bad. Nobody really does that, so whatever happens in these cases is mostly irrelevant. For me it's easier to check and fix all inconsistencies at on

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On Tue, May 24, 2016 at 5:54 PM, Yasuo Ohgaki wrote: > Jesse, > > $this must be a object you're accessing. > Why? I consider it a kind of implied parameter. You can reassign self in Python for example. class MyClass: def foo(self, p1, p2): self = 7 print(self, p1, p2) c = M

RE: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

> -Original Message- > From: jesseschal...@gmail.com [mailto:jesseschal...@gmail.com] On > Behalf Of Jesse Schalken > Sent: Tuesday, May 24, 2016 11:42 AM > To: Yasuo Ohgaki > Cc: Dmitry Stogov ; internals ; > Nikita Popov ; Bob Weinand ; Xinchen Hui > > Subject: Re: [PHP-DEV] [RFC] Fix

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

After the latest changes the patch became better. >From a quick look I see two issues. The following 3 tests are failed (crashed with opcache.protect_memory=1) > Test typed properties float widen at runtime > [Zend/tests/type_declarations/typed_properties_027.phpt] > Test typed properties resp

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

On May 23, 2016 4:09 PM, "Stanislav Malyshev" wrote: > > Hi! > > > 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

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 24/05/2016 06:45, Jesse Schalken wrote: I'm curious, what is it about $this that makes it special in the first place? Can't it be a normal local variable that happens to already be assigned at the start of a method? There are a few things that take advantage of its specialness, e.g. - bindi

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2016-05-24

Results for project PHP master, build date 2016-05-24 06:27:56+03:00 commit: 0cdbabe previous commit:0d62dfd revision date: 2016-05-23 10:14:26+03:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] VCS Account Request: cranavvo

Overall PHP maintenance by the guidelines. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Exception::getLine()

> it would be more logical to collect the trace in the ZEND_THROW Opcode > instead of in the create_handler of the Exception class I've been pondering a means of doing this with relatively few BC issues. There are four use-cases right now: 1. Direct: throw new Exception() 2. Indirect: throw $fa

Re: [PHP-DEV] Exception::getLine()

On 24/05/2016 16:32, Rasmus Schultz wrote: The second use-case (indirect throw, factory) and third use-case (re-throwing) are both broken as-is - in either case, it isn't reporting the correct stack-trace now. This change corrects those cases. Even if that's a minor BC break, it corrects an error

Re: [PHP-DEV] Allow empty property names

On Sun, May 8, 2016 at 5:04 PM, Jakub Zelenka wrote: > Hi, > > I have been thinking about it and I would be ok with removing _empty_ in > 7.1. That inconsistency is quite annoying and I never liked it. If we can > rid of it, that would be great! I realise the BC concern but I see that > more as a

Re: [PHP-DEV] Exception::getLine()

2016-05-24 17:32 GMT+02:00 Rasmus Schultz : > > it would be more logical to collect the trace in the ZEND_THROW Opcode > instead of in the create_handler of the Exception class > > I've been pondering a means of doing this with relatively few BC issues. > > There are four use-cases right now: > >

Re: [PHP-DEV] Exception::getLine()

+1 There is use case - exception without backtrace, used to global return. Example REST API throw new RedirectExeception('/url', 302); // creating in backtrace is overhead -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

On Tue, May 17, 2016 at 4:33 PM, Nikita Popov wrote: > On Sun, May 15, 2016 at 10:46 PM, Nikita Popov > wrote: > >> Hi internals, >> >> The RFC >> >> https://wiki.php.net/rfc/forbid_dynamic_scope_introspection >> >> is now in voting. The vote closes on 2016-05-24 with a required majority >>

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

Hi Joe, I've add implementation for nullable typed properties (as they fit into the patch design), but RFC missed any description of nullable properties. See tests Zend/tests/type_declarations/typed_properties_047.phpt, Zend/tests/type_declarations/typed_properties_048.phpt, Zend/tests/type_

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 05/24/2016 11:57 AM, Rowan Collins wrote: On 24/05/2016 06:45, Jesse Schalken wrote: I'm curious, what is it about $this that makes it special in the first place? Can't it be a normal local variable that happens to already be assigned at the start of a method? There are a few things that t

Re: [PHP-DEV] [RFC] Fix inconsistent behavior of $this variable

On 24/05/2016 20:21, Marc Bennewitz wrote: As of $this is a very special variable where only the engine is (or should) be allowed to change. I would like to ask you if it wouldn't be better to NOT define $this as a special variable including a lot of code to make sure this variable doesn't get

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

Morning Dmitry, There's no section for nullables, but there is mention of them, specifically in relation to your query: > While parameters allow null to be accepted as the default value, null is only a valid value for nullable properties. Is there something wrong with that rule ? Ha