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 elsewhere, where a trait
> > pro
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:
http://www.php.net/downl
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
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 {
>
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 "l
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 deprecat
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 remo
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
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:
http://ww
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
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:
http://www.
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 sh
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
(https://gist.github.com/
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 quite
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
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. Add
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 h
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 argum
18 matches
Mail list logo
