Re: Fw: [PHP-DEV] RFC Proposal: Pluggable Mail Transports

> From: Ángel González > On Sunday, February 28, 2016 21:12, Ángel González wrote: > I don't think more than a direct SMTP transport will be needed (LMTP > perhaps?), but it seems a good idea that #29629 can finally be fixed. > These would indeed be a few examples. Although

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

On Thu, Mar 10, 2016 at 8:47 PM, Pierrick Charron wrote: > Just to let you know that I took the liberty to correct the title of your > RFC. It was still null coalesce equal operator :) > Ooops. Thanks :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe,

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

Hi Sara, Just to let you know that I took the liberty to correct the title of your RFC. It was still null coalesce equal operator :) Otherwise I'm +1 for both RFC Pierrick On 10 March 2016 at 22:01, Sara Golemon wrote: > On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak

Re: [PHP-DEV] segfault in ini_lex() in 7.0.3

On Wed, Mar 9, 2016, at 03:51 PM, Adam Baratz wrote: >> Can you provide the INI (minus secure info) and script that generates >> this? > > Unfortunately, I haven't been able to isolate what's causing this. It > seems to occur on "complex enough" pages. Which could mean one of the > (many)

Re: [PHP-DEV] [RFC Proposal] Null Coalesce Equal Operator

On Wed, Mar 9, 2016 at 10:14 AM, Midori Kocak wrote: > Let me introduce my first RFC here: > https://wiki.php.net/rfc/null_coalesce_equal_operator > > I've jumped on the bandwagon by adding a second RFC related to this one: https://wiki.php.net/rfc/short_ternary_equal_operator

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

Hi! On Fri, Mar 11, 2016 at 2:14 AM, Colin O'Dell wrote: > I have completed my initial draft of the RFC to deprecate "var" in favor of > "public": https://wiki.php.net/rfc/var_deprecation > > I would greatly appreciate any feedback on this RFC, especially with the >

Re: [PHP-DEV] Re: [RFC Discussion] "var" Deprecation

On 10/03/2016 20:19, Lester Caine wrote: I have no problem with code needing to be updated, it's the unnecessary pressure that it has to be done now when there is no gain currently from spending that time. To be clear, the pressure added by this deprecation would be to do it "sometime in the

Re: [PHP-DEV] Re: [RFC Discussion] "var" Deprecation

On 10/03/16 17:16, Colin O'Dell wrote: > - Ensuring that all major arguments for & against have been documented. While the no-brain conversion of one to the other may be acceptable to some, it's both the follow though on associated documentation and a proper review of the code which is CURRENTLY

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

Hi! > I have completed my initial draft of the RFC to deprecate "var" in favor of > "public": https://wiki.php.net/rfc/var_deprecation As I already stated here, I think this is needless change which only creates BC problems and does not add anything to the language. The RFC incorrectly claims

Re: [PHP-DEV] [RFC Discussion] "var" Deprecation

Colin O'Dell wrote on 10/03/2016 17:14: Hello all, I have completed my initial draft of the RFC to deprecate "var" in favor of "public": https://wiki.php.net/rfc/var_deprecation Hi Colin, Thanks for a very thorough RFC, particularly in clearly expressing the arguments for and against,

[PHP-DEV] Re: [RFC Discussion] "var" Deprecation

My apologies, I posted the wrong discussion link. Here's the correct one: http://markmail.org/message/wn3ykdwgplfctho7 Colin On Thu, Mar 10, 2016 at 12:14 PM Colin O'Dell wrote: > Hello all, > > I have completed my initial draft of the RFC to deprecate "var" in favor >

[PHP-DEV] [RFC Discussion] "var" Deprecation

Hello all, I have completed my initial draft of the RFC to deprecate "var" in favor of "public": https://wiki.php.net/rfc/var_deprecation I would greatly appreciate any feedback on this RFC, especially with the following: - Ensuring that all major arguments for & against have been documented. -

[PHP-DEV] Re: VCS Account Request: edgarsandi

VCS Account Rejected: edgarsandi rejected by rasmus /o\ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Enabling opcache causes libraries to build as static

> On 08.03.2016, at 16:18, Andrea Faulds wrote: > > Hi, > > David Zuelke wrote: >> Is this intentional? Related to opcache's "can only be built shared" status? >> But why would that trigger static builds? Or is it a bug? > > While we're at it, why is Opcache still built as

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

as @Arvids said, var is missing functionality that public has, so they are not exact aliases of each other. i think this is valid enough reason to remove it. even if it weren't the case, I would say let the language maintainers decide if this cleanup would be worth it to them and make their lives

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

Tony Marston wrote on 10/03/2016 10:28: some inconsiderate and self-centered group of individuals has unilaterally decided There is no conspiracy. You are contributing to the list where the decisions are made. If you think the decision-making process can be improved, help us improve it. If

[PHP-DEV] GOOD Benchmark Results for PHP Master 2016-03-10

Results for project PHP master, build date 2016-03-10 06:31:08+02:00 commit: 97a88fc previous commit:f2d2e8c revision date: 2016-03-09 23:01:51+01: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] [RFC Proposal] var keyword deprecation/removal

Tony Marston wrote on 10/03/2016 10:38: "Rowan Collins" wrote in message news:56e0025c.5040...@gmail.com... This leaves us back with a decision about *which* BC breaks are acceptable, discussion of which includes how many people use the feature, how it will affect them, and what the benefits

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

Le jeudi 10 mars 2016, 10:28:58 Tony Marston a écrit : > It is perfectly legitimate to question the competence, professionalism, and > intelligence of any individual (or group) who seeks to break BC for NO GOOD > REASON other than personal preference. > I don't mind a language that evolves with

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

On Thu, 10 Mar 2016, 12:29 Tony Marston, wrote: > "James Titcumb" wrote in message > news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9qyzphtupuwax...@mail.gmail.com... > > > >> > >> need to have their competence, professionalism, and intelligence > >> questioned. > > > >Tony,

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

> > It is perfectly legitimate to question the competence, professionalism, > and intelligence of any individual (or group) who seeks to break BC for NO > GOOD REASON other than personal preference. As has already stated, you are insulting people by doing this. Please stop insulting people; as

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

"Rowan Collins" wrote in message news:56e0025c.5040...@gmail.com... Tony Marston wrote on 09/03/2016 10:31: As a developer who went through several COBOL upgrades I can attest to the fact that BC breaks were extremely rare and only for a good reason. My code was never affected simply because

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

"Arvids Godjuks" wrote in message news:CAL0xaBF-cx+hijFD=YNiihhKknpxwo0JdO+oNRada=b0jyy...@mail.gmail.com... All languages are evolving, and part of that is removing old baggage, even if that baggage is harmful. Because ease of maintenance. When you have multiple ways to do a thing, that means

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

"James Titcumb" wrote in message news:CAKnqCEZMh-P8XmAeQtdPnw4ZaZGb4=wmm_9qyzphtupuwax...@mail.gmail.com... need to have their competence, professionalism, and intelligence questioned. Tony, making a statement like this is unprofessional in itself. You've already been asked to put emotions