> 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
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,
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
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)
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
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
>
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
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
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
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,
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
>
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.
-
VCS Account Rejected: edgarsandi rejected by rasmus /o\
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> 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
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
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
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
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
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
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,
>
> 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
"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
"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
"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
24 matches
Mail list logo