Re: [PHP-DEV] Re: [RFC] Traits with interfaces

On Thu, Mar 3, 2016 at 2:19 PM, Stephen Coakley wrote: > On Wed, 17 Feb 2016 09:25:50 -0500, Kevin Gessner wrote: > > > Hello internals team! I'd like to propose an RFC to allow traits to > > implement interfaces. > > > > I've noticed s pattern in Etsy's code and

[PHP-DEV] PHP 5.6.19 is available

Hello! The PHP development team announces the immediate availability of PHP 5.6.19. Several security related issues were fixed in this release. All PHP 5.6 users are encouraged to upgrade to this version. For source downloads of PHP 5.6.19 please visit our downloads page:

[PHP-DEV] Re: [RFC] Traits with interfaces

On Wed, 17 Feb 2016 09:25:50 -0500, Kevin Gessner wrote: > Hello internals team! I'd like to propose an RFC to allow traits to > implement interfaces. > > I've noticed s pattern in Etsy's code and elsewhere, where a trait > provides a common implementation of an interface. Classes that use the

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

On 3/3/2016 6:48 PM, Rowan Collins wrote: > There's a subtle distinction which I may not have explained very well. > What I want is the ability to *selectively* ignore these warnings. For > instance, if I write: > > namespace \Foo\Bar\Baz; > class AwesomenessFactory implements ArrayAccess { >

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

Fleshgrinder wrote on 03/03/2016 17:32: If there were some way of preventing users writing var in*new* code, I >would be all for it - there is no advantage to doing so, and it adds no >value to have two ways of writing "public". But there is no way for the >engine to distinguish new code from

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

On 3/3/2016 6:14 PM, Rowan Collins wrote: > Having no plans to use something doesn't make it a problem. There still > needs to be some actual problem you are solving by removing it. I think in general that it would be helpful to have clear guidelines regarding such topics. They would make

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

Fleshgrinder wrote on 03/03/2016 16:53: The fact that there are no plans regarding the old syntax and thus keeping the duplication indefinitely is the actual problem. Having no plans to use something doesn't make it a problem. There still needs to be some actual problem you are solving by

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

On 3/3/2016 10:34 AM, Tony Marston wrote: > If you want to avoid such confusion over alias names then surely that > would be an argument against introducing aliases in the first place. In > this case the short array syntax would never have been introduced as the > (only slightly longer) long array

[PHP-DEV] PHP 5.5.33 is available

Hi, The PHP development team announces the immediate availability of PHP 5.5.33. This is a security release. Several security bugs were fixed in this release. All PHP 5.5 users are encouraged to upgrade to this version. For source downloads of PHP 5.5.33 please visit our downloads page:

[PHP-DEV] BAD Benchmark Results for PHP Master 2016-03-03

Results for project PHP master, build date 2016-03-03 06:31:23+02:00 commit: de3e033 previous commit:42788d6 revision date: 2016-03-02 17:06:03+01:00 environment:Haswell-EP cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 2, LLC 45 MB

[PHP-DEV] PHP 7.0.4 is available

Hi, The PHP development team announces the immediate availability of PHP 7.0.4. This is a security release. Several security bugs were fixed in this release. All PHP 7.0 users are encouraged to upgrade to this version. For source downloads of PHP 7.0.4 please visit our downloads page:

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

On Wed, 2016-03-02 at 19:40 +0100, Fleshgrinder wrote: > It showcases what the studies about UI/UX found out about duplicated > behavior (or call it aliasing, multiple choices for the same thing, ...). > > People are confused and we can and should avoid that. Yes, duplication isn't good and we

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

Lester Caine wrote on 03/03/2016 13:18: Actually my problem is even more simple than that - although it may be possible to further filter the lookup for 'var ' ( note the space ) many of the results are simply not text that needs changing. The script that Colin linked

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

On 03/03/16 13:04, Rowan Collins wrote: > Colin O'Dell wrote on 03/03/2016 12:47: >> If you're staying on PHP 5.x or 7.0, no changes would be needed. If >> you're >> upgrading to 7.1+, you would need to either hide deprecation notices or >> take 30 seconds to run that script. > > This isn't

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

Colin O'Dell wrote on 03/03/2016 12:47: If you're staying on PHP 5.x or 7.0, no changes would be needed. If you're upgrading to 7.1+, you would need to either hide deprecation notices or take 30 seconds to run that script. This isn't quite true. At the moment, PHP has no mechanism for hiding

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

Lester, > The problem with 'var' is that while one should probably > replace them all with public, there is a lot of simple legacy code still > in active use that could take years to 'tidy' 'var' would not be removed until 8.x, so you'd have several years before needing to make code changes.

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

On 03/03/16 09:34, Tony Marston wrote: >> The "var" keyword once emitted an E_STRICT but I guess it was turned off >> again because too many people were complaining as they are now. > > So if people are still using it then surely that is an argument AGAINST > its removal. The underlying problem

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

wrote in message news:56d73386.3000...@fleshgrinder.com... On 3/2/2016 11:09 AM, Rowan Collins wrote: I think the point was that *the difference between* "var" and "public" was being abused, which wouldn't be possible if there were only one keyword. However, I agree that it's a very weak