While overall I tend to agree with Paul on the concept of a CoC, I don't
think that precludes the ability to offer suggestions. It's to everyone's
advantage to make sure that if we do adopt a CoC, we adopt the best one
possible.
Obviously one of the biggest fears is unjust treatment of the
On Thu, Jan 7, 2016 at 3:21 PM, Pierre Joye <pierre@gmail.com> wrote:
>
> On Jan 8, 2016 3:14 AM, "Chase Peeler" <chasepee...@gmail.com> wrote:
>
> >
> > And none of those caveats exist in the definition you provided.
>
> Hmmm. W
On Thu, Jan 7, 2016 at 3:37 PM, Pierre Joye <pierre@gmail.com> wrote:
>
> On Jan 8, 2016 3:34 AM, "Chase Peeler" <chasepee...@gmail.com> wrote:
> >
> >
> >
> > On Thu, Jan 7, 2016 at 3:21 PM, Pierre Joye <pierre@gmail.com>
>
The way I see this, and I believe others do as well based on the previous
recommendation to split this into two RFCs, is there are two goals:
1.) Making it clear that the community welcomes all individuals
2.) A means for handling conflict resolution.
To me, #1 doesn't really fall into a "Code of
I personally offered at least two emails with constructive feedback and
alternative solutions. I never saw any reply or feedback to either one. I
also had some emails in which I was somewhat argumentative (the ones
related to the definition of harassment). I still stand by those emails as
they
Let's look at this from the perspective of a conflict mediation standpoint
On Fri, Jan 8, 2016 at 11:55 AM Anthony Ferrara wrote:
> Keith,
>
> On Fri, Jan 8, 2016 at 11:38 AM, D Keith Casey
> wrote:
> > On 1/7/16 11:52 PM, Larry Garfield wrote:
>
On Fri, Jan 8, 2016 at 10:49 AM Anthony Ferrara wrote:
> Kevin,
>
> On Fri, Jan 8, 2016 at 10:39 AM, Kevin Smith wrote:
> >
> >
> >> On Jan 8, 2016, at 9:09 AM, Anthony Ferrara
> wrote:
> >>
> >>
> >> Simply look at the level of
On Fri, Jan 8, 2016 at 12:28 PM Paul M. Jones wrote:
>
> > On Jan 7, 2016, at 23:52, Larry Garfield wrote:
> >
> > Do you think we can find 5 people in the PHP community that we can trust
> to make fair decisions (NOT that we would always agree with,
On Mon, Jan 11, 2016 at 12:52 PM Pierre Joye wrote:
> On Jan 11, 2016 8:47 PM, "Brandon Savage"
> wrote:
> >
> > >
> > > At the same time, though, if someone is being maliciously hostile what
> > > great cover! A private email is not a PHP-Group
On Wed, Jan 13, 2016 at 2:46 PM Larry Garfield
wrote:
> On 1/13/16 1:18 PM, Tom Worster wrote:
> > On 1/12/16 5:58 PM, Stanislav Malyshev wrote:
> >
> >> But we can not change the conduct of "whole of internals as a group".
> >
> > Yes we can!
> >
> > Let's say *we* would
On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner wrote:
> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley wrote:
>
> > This isn't such a great idea as it will cause some of traits
> functionality
> > to be broken: I can currently use a trait and alias its
ony and Derick for carrying this RFC.
>
> Now… I have one issue with this argument :
>
> Chase Peeler a écrit le 22/01/2016 19:15 :
> > 3.) Finally, I think a Code of Conduct that includes punitive
> > measures is a bad idea. I won't go into details on why, as we've
> >
On Fri, Jan 22, 2016 at 2:42 PM John Bafford <jbaff...@zort.net> wrote:
> Chase,
>
> On Jan 22, 2016, at 13:15, Chase Peeler <chasepee...@gmail.com> wrote:
> >
> > 1.) I think everyone already knows how to be an adult. The fact that
> > sometimes we don't
I just want to reiterate what I've said a few times before. I'm leaving the
points about why I think a Code of Conduct, in general, is a bad idea until
the end, in hopes that others will at least read my other points. I don't
think there is anything "new" in what I'm saying below either - I'm
I agree. with Sebastian. I'm personally a big fan of using traits as the
implementation mechanism for interfaces (i.e. implement the interfaces
methods in a trait, then use that trait in a class that implements the
interface), but I don't think there is anything positive to gain from
having the
On Thu, Feb 18, 2016 at 5:35 AM Larry Garfield
wrote:
> On Wed, Feb 17, 2016, at 01:05 PM, Kevin Gessner wrote:
> > On Wed, Feb 17, 2016 at 9:25 AM, Kevin Gessner
> wrote:
> >
> > > Hello internals team! I'd like to propose an RFC to allow traits to
>
On Thu, Feb 18, 2016 at 1:29 PM Nikita Popov wrote:
> On Wed, Feb 17, 2016 at 3:25 PM, 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
On Fri, Feb 19, 2016 at 2:13 PM Kevin Gessner <kgess...@etsy.com> wrote:
> On Thu, Feb 18, 2016 at 2:16 PM, Chase Peeler <chasepee...@gmail.com>
> wrote:
>
>> On Thu, Feb 18, 2016 at 1:29 PM Nikita Popov <nikita@gmail.com>
>> wrote:
>>
> H
On Fri, Feb 19, 2016 at 2:42 PM Fleshgrinder <p...@fleshgrinder.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2/19/2016 8:34 PM, Chase Peeler wrote:
> > My comments above, however, were more in relation to the HHVM
> > notion of "re
On Thu, Jun 14, 2018 at 12:45 PM Rowan Collins
wrote:
> On 14 June 2018 at 17:16, Alice Wonder wrote:
>
> >
> > Should declare(strict_types = 1) do that?
> >
> > I haven't tried, but I would think it should.
>
>
>
> No, it doesn't, and shouldn't. "strict_types" actually means
>
>
>
> > If $left operand and $right operand both have the magic methods, it will
> call $left->__magic($right), otherwise, if only the right one has the
> handler? What if the right one has compareTo and the left has only equal?
> you probably should add a table that explains which method is
On Wed, Jun 27, 2018 at 11:46 AM niel wrote:
> On 24/06/18 17:16, Nikita Popov wrote:
> > Hi internals,
> >
> > Another small deprecation for your consideration...
> >
> > https://wiki.php.net/rfc/continue_on_switch_deprecation
> >
> > Regards,
> > Nikita
> >
>
> Could you clarify the PHP 8
On Mon, Jun 25, 2018 at 1:16 PM Mark Baker wrote:
> On 24/06/2018 18:23, Rowan Collins wrote:
> > I've argued before that there should be a roadmap and a cycle for major
> releases, and if not, then some agreement on what triggers one, but we've
> so far not managed to agree either.
>
> I do
if email clients that allowed
filtering were expensive or hard to find. They aren’t, though. Pretty much
every email client not only allows filtering, but rather advanced filtering
as well.
Instead of suspending users, no matter how egregious their offenses may be,
let individual users filter them out as they see fit.
> <http://www.php.net/unsub.php>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev <n...@devilix.net> wrote:
> Hi,
>
> On Wed, Jan 3, 2018 at 6:05 PM, Chase Peeler <chasepee...@gmail.com>
> wrote:
> >
> > I agree with Paul. It would be different if email clients that allowed
> > filtering w
Peter Lind <peter.e.l...@gmail.com> wrote:
>
>
> On 3 Jan 2018 18:13, "Chase Peeler" <chasepee...@gmail.com> wrote:
>
> On Wed, Jan 3, 2018 at 11:16 AM Andrey Andreev <n...@devilix.net> wrote:
>
> > Hi,
> >
> > On Wed, Jan 3,
On Wed, Jan 3, 2018 at 12:18 PM Michael Morris <tendo...@gmail.com> wrote:
> On Wed, Jan 3, 2018 at 11:05 AM, Chase Peeler <chasepee...@gmail.com>
> wrote:
>
> > On Wed, Jan 3, 2018 at 10:49 AM Paul Jones <pmjone...@gmail.com> wrote:
> > > > On
On Wed, Dec 12, 2018 at 11:15 AM Anatol Belski wrote:
> Hi Sara,
>
> > -Original Message-
> > From: Sara Golemon
> > Sent: Tuesday, December 11, 2018 5:20 PM
> > To: Dmitry Stogov
> > Cc: PHP internals
> > Subject: Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface
> >
> > I'm not
oking at past
> vote frequency, but say 4 months or 10 votes, whichever is longer.
>
> Peter
>
For this to have meaningful results, I think you would also need the
ability for people to abstain, along with a comment as to why they aren't
voting.
--
Chase Peeler
chasepee...@gmail.com
e disadvantages. I'm not seeing that in this case.
> [1] https://w3techs.com/technologies/details/pl-php/all/all
>
> rr
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ocumentation to remove the second list - anything not in
the first list is not affected.
3.) Update the language so that ++ and -- cast booleans to ints.
I don't think #3 is actually a good solution.
> - Chris
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Mon, Mar 4, 2019 at 11:25 AM Johannes Schlüter
wrote:
> On Mo, 2019-03-04 at 07:30 -0800, Steven Penny wrote:
> > On Mon, 04 Mar 2019 02:23:46, Peter Kokot wrote:
> > >
> > > Now, interesting is that in bash and some langs (where the main
> > > environment is CLI), there is by default newline
On Wed, Mar 13, 2019 at 4:26 PM Travis van der Font
wrote:
> Arrow functions are ternary operators to functions.
> While they are nice and shorten, they can be hard to read at times;
> considerably to people who aren't used to them which is surprisedly a
> majority of PHP programmers.
>
> Having
On Tue, Mar 12, 2019 at 10:12 AM Kalle Sommer Nielsen wrote:
> Hi
>
> Den tir. 12. mar. 2019 kl. 15.49 skrev Chase Peeler >:
> > Everything looks weird and "non-phpish" when it's new. OO constructs
> weren't PHP-ish at first, because PHP didn't originally support
On Tue, Mar 12, 2019 at 4:55 AM Kalle Sommer Nielsen wrote:
> Hi
>
> Den søn. 10. mar. 2019 kl. 23.45 skrev Larry Garfield <
> la...@garfieldtech.com>:
> >
> > Hello, peoples. I know it's been discussed once or twice before on the
> list, many years ago, but not recently. I therefore feel OK
On Fri, Mar 22, 2019 at 3:41 AM Joe Watkins wrote:
> Morning Niklas,
>
> Allowing the extension of voting leaves us open to someone extending the
> voting period simply because they don't feel like they have the result they
> wanted.
>
> The problem we're trying to solve is votes that are too
On Tue, Feb 5, 2019 at 1:46 PM Rowan Collins
wrote:
> On Tue, 5 Feb 2019 at 17:25, Craig Duncan wrote:
>
> > The *iterable* type accepts a plain array, but not an object that is used
> > to represent a plain array, that's surprising to me.
> >
>
>
> I think this notion of stdClass as "an object
On Mon, Feb 11, 2019 at 11:35 AM Levi Morrison wrote:
> >> I recognize that there is one downside, which is that lazy evaluation
> >> is lost, but generally don't see it to be an issue in these specific
> >> cases.
> >>
> > Lazy evaluation doesn't have to be lost if the all_of and any_of
>
On Mon, Feb 11, 2019 at 10:59 AM Levi Morrison wrote:
> On Mon, Feb 11, 2019 at 8:39 AM Woortmann, Enno
> wrote:
> >
> > Hi internals,
> >
> > as I reviewed a bunch of code for handling data from different sources
> > (eg. json) in the last days I stumbled over code like this multiple
> times:
On Thu, Jan 31, 2019 at 11:52 AM Zeev Suraski wrote:
> On Thu, Jan 31, 2019 at 5:58 PM Kalle Sommer Nielsen
> wrote:
>
> > Hi Zeev
> >
> > Den tor. 31. jan. 2019 kl. 15.44 skrev Zeev Suraski :
> > >
> > > Without further ado, an RFC that’s attempting to comprehensively solve
> > many of the
On Thu, Jan 31, 2019 at 12:04 PM Zeev Suraski wrote:
> On Thu, Jan 31, 2019 at 6:47 PM Kalle Sommer Nielsen
> wrote:
>
> > Without my usual Windows bias, I do believe it is a considerable fact
> > like Nikita pointed out as Windows is a first class citizen in terms
> > of operating systems we
HP Driver / Maintainer
> >
> > ===8<==Original message text=== Hello Helen,
> >
> > hope everything is running smoothly in the Southern hemisphere ;-)
> >
> > I would like to give you an update on . The voting to exclude
> the
> > driver from the main php distribution has started (only people on the
> > php.internals mailing list can vote, http://news.php.net/php.internals)
> and
> > as expected it is not looking good:
> >
> > https://wiki.php.net/rfc/deprecate-and-remove-ext-interbase
> >
> > Today Martin has finally succeeded to get into the internal php-mailing
> > list, after he had contacted some guys of the core php team directly.
> Let's
> > see ...
> >
> > best, Volker
>
>
> --
> regards,
>
> Kalle Sommer Nielsen
> ka...@php.net
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
e a reason adding such an option as a new parameter wouldn't work for
other methods, like getcwd?
> Greetings,
> Gert de Pagter (BackEndTea)
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
gt; L.S.Caine Electronic Services - https://lsces.co.uk
> EnquirySolve - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay
wrote:
>
> > On 24 Apr 2019, at 21:35, Chase Peeler wrote:
> >
> > If I get started now, maybe I can have everything fixed by the time 8.1
> is
> > released.
>
>
> Two characters less than this sentence
On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay
wrote:
>
> > On 24 Apr 2019, at 22:16, Chase Peeler wrote:
> >
> >
> >
> > On Wed, Apr 24, 2019 at 11:02 AM Stephen Reay <mailto:php-li...@koalephant.com>> wrote:
> >
> > > On 24 Apr 20
k. No one ever responded to even one of those points.
> Peter
>
> On Wed, 24 Apr 2019 at 16:51, Chase Peeler wrote:
>
>> On Wed, Apr 24, 2019 at 11:27 AM Stephen Reay
>> wrote:
>>
>> >
>> > > On 24 Apr 2019, at 22:16, Chase Peeler wrote:
e - https://enquirysolve.com/
> Model Engineers Digital Workshop - https://medw.co.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.co.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta wrote:
> On Wed, 24 Apr 2019, 19:25 Christian Schneider,
> wrote:
>
> > Am 24.04.2019 um 19:13 schrieb Marco Pivetta :
> > > On Wed, 24 Apr 2019, 19:10 Christian Schneider, >
> > wrote:
> > > Am 24.04.2019 um 19:01 schrieb Peter Kokot :
> > > >
On Wed, Apr 24, 2019 at 12:06 PM Mark Randall wrote:
> On 24/04/2019 15:35, Chase Peeler wrote:
> >> Total files scanned: 20,767
> > Total lines scanned: 4,013,170
> > Total short open tag references: 6,787
> > Total files w/ short open tag references: 1,665
&
gt;
> > George P. Banyard
> >
> > >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
t involves risk with no reward.
> - Chris
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
now (and not in the discussion
> phase) because for some time in the voting there wasn't the 2/3 majority
> for the 7.4 (so no sense to clutter the list) and now in the end only 1-2
> votes make the difference.
> >
> > rr
> >
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
--
Chase Peeler
chasepee...@gmail.com
On Wed, Apr 24, 2019 at 3:07 PM Peter Kokot wrote:
> Hello,
>
> On Wed, 24 Apr 2019 at 19:44, Chase Peeler wrote:
> >
> > On Wed, Apr 24, 2019 at 1:27 PM Marco Pivetta
> wrote:
> >
> > > On Wed, 24 Apr 2019, 19:25 Christian Schneider, >
> &g
up due to the
fact that most responses just said "it's easy to make the updates." The
potential for code leaks actually concerned me more. I think the above
proposal addresses that well.
--
Chase Peeler
chasepee...@gmail.com
what my email said
> to my reading.
>
> The problem I see is that if we don't commit to anything, then we stand for
> everything and nothing.
>
>
> Any thoughts on governance and the lack of consensus over who should/should
> not have a say in what happens?
>
> Peter
>
--
Chase Peeler
chasepee...@gmail.com
's decision, or, it makes the whole
reason for having made a decision pointless if we keep finding certain
items that are exceptions.
> Mark Randall
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
mobile and web application designed).
>
> Please,clean up.
>
> >
>
The "shake-ups" that will draw people to PHP are the new features, the
majority of which don't require BC breaks and were listed earlier in this
thread. Go find a group of anti-PHP developers. Tell them
led.
There might be a time in the future where I do feel like a proposal like
this is justified or even needed. I just don't feel we are at that point
right now, nor do I think we are headed towards it.
--
Chase Peeler
chasepee...@gmail.com
n, I wouldn't be as
vocal. I can suck it up and fix things. I can cut through the red tape and
get it done at some point so we can upgrade. I'm vocal on this because I
know there are other developers out there dealing with a legacy code base
like mine, if not worse, that might not be able to just bite the bullet and
get it done.
> Regards,
> Robert Korulczyk
>
--
Chase Peeler
chasepee...@gmail.com
seems like a security
risk as well, since error messages can contain sensitive information. I
know keeping/removing it isn't mutually exclusive with keeping/removing
short tags. I'm just curious why it's never mentioned by anyone that
suddenly is so concerned about the security implications of short tags.
>
>
> Regards,
> Robert Korulczyk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
If there is any documentation that
doesn't make this clear, submit a bug report.
If you really feel that we should start treating short tags as totally
legitimate, then someone else with better knowledge of how to proceed with
that will need to provide advice.
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ifferent versions / generations in the
> same package.
>
My first reply got rejected by the listserv for being too big. I cleaned up
some the quoted text, but I apologize if anyone sees this twice.
Chase Peeler
chasepee...@gmail.com
folks with a solution
> in the form of 'use strict;' decades ago; JS did something similar much
> more recently. Neither of these created any sort of bifurcation - it's a
> simple, sensible solution that has virtually no downsides.
>
> While I like Zeev's idea of making it opt-in, I think that a deprecation
path is needed at the very least. I think this has the potential to be an
even bigger issue to deal with than short tags. At least short tags have
been discouraged for a long time. The first short tags RFC would have
probably lead to a delay in upgrading to 8.0. This RFC would pretty much
guarantee never being able to upgrade to 8.0 until we've totally retired
our legacy code base... which will probably be just in time for PHP 28.0 -
assuming the PHP project isn't dead at that point due to this RFC.
> Zeev
>
--
Chase Peeler
chasepee...@gmail.com
type of changes, which are destined to
be rejected, or, evidence that we are still in danger of having such a
precedent set.
On Wed, Aug 28, 2019 at 10:11 AM Chase Peeler wrote:
>
>
> On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald
> wrote:
>
>>
>>
>> Am 28.08
On Wed, Aug 28, 2019 at 9:30 AM Chase Peeler wrote:
>
>
> On Wed, Aug 28, 2019 at 8:35 AM Zeev Suraski wrote:
>
>> On Wed, Aug 28, 2019 at 2:10 PM Nikita Popov
>> wrote:
>>
>> > On Wed, Aug 28, 2019 at 12:41 PM Zeev Suraski wrote:
>> >
>>
On Wed, Aug 28, 2019 at 9:55 AM Reindl Harald
wrote:
>
>
> Am 28.08.19 um 15:48 schrieb Chase Peeler:
> > If it is still done, then I think a deprecation path is a must. As
> > mentioned earlier, this doesn't necessarily mean E_DEPRECATION messages -
> > warn
nerates about 5-10 megs of logs in a day. Our CLI servers (which runs
beanstalkd jobs) generates about 80-100 megs of logs in a day. That's
without notices turned on.
> On Wed, 28 Aug 2019 at 16:16, Chase Peeler wrote:
> >
> > Well, one reason I was so vocal about short tags wasn't a l
On Wed, Aug 28, 2019 at 11:37 AM Kalle Sommer Nielsen wrote:
> Hi
>
> Den ons. 28. aug. 2019 kl. 17.54 skrev Chase Peeler >:
> > You going to come and fix the issues? It's an internal application and
> > most of those messages are coming from legacy areas of the c
On Wed, Aug 28, 2019 at 10:39 AM Marco Pivetta wrote:
> On Wed, Aug 28, 2019 at 4:27 PM Chase Peeler
> wrote:
>
>> On Wed, Aug 28, 2019 at 10:20 AM Gert wrote:
>> Notices include a lot more than just undeclared variables. Turning them on
>> in our environment woul
On Wed, Aug 28, 2019 at 11:12 AM Mark Randall wrote:
> On 28/08/2019 15:54, Chase Peeler wrote:
> > Bottom line is that we live with the not-so-good stuff so that we can
> focus
> > on adding new great stuff. The not-so-good stuff isn't holding us back,
> and
> >
On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
> On 28/08/2019 16:37, Chase Peeler wrote:
> > I'm also not the one that built it on the eggshells - I'm just the one
> that
> > is now in charge of developing the system that someone else left sitting
> > eggshells
here are plenty that still
operate that way today.
> On Wed, 28 Aug 2019 at 12:26, Chase Peeler wrote:
>
> > On Wed, Aug 28, 2019 at 12:12 PM Mark Randall wrote:
> >
> > > On 28/08/2019 16:37, Chase Peeler wrote:
> > > > I'm also not the o
only generate a notice - given the fact that how PHP handles
undeclared variables is will documented and, in my opinion, actually a
feature of the language?
> I was hoping that the glaring obviousness of how other languages tackled
> similar issues (Perl, JS) would go a longer way. It should.
>
> Zeev
>
--
Chase Peeler
chasepee...@gmail.com
is response:
"I’ve never heard of a breaking change when new versions of C# are
released. There are occasionally breaking changes when upgrading to a new
version of .NET, but they always (as far as I’m aware) have a way to
prevent the change from breaking anything by adding a parameter the app’s
configuration."
--
Chase Peeler
chasepee...@gmail.com
wn everything precisely, and having to
> write explicitly and once for all that, yes, this precise variable must
> have that default value, is a minimal part of the time passed to write,
> re-read and review the code.
>
> What??? You mean it's possible to write strict code even when
On Thu, Sep 12, 2019 at 10:06 AM Arvids Godjuks
wrote:
>
>
> чт, 12 сент. 2019 г. в 16:02, Chase Peeler :
>
>> On Thu, Sep 12, 2019 at 9:55 AM Claude Pache
>> wrote:
>>
>> >
>> >
>> > > Le 12 sept. 2019 à 15:33, Marco Pivetta a écri
rror handler like
you mentioned above, stricter code reviews, public shaming for anyone that
doesn't initialize their variables, or any of the myriad of other options.
> Best,
> Jordi
>
> --
>
> Jordi Boggiano
> @seldaek - https://seld.be
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
ntroversial during the discussion, the last one is for
> > the remainder of the proposal.
> >
> > Voting closes 2019-09-26.
> >
> > Regards,
> > Nikita
> >
>
--
Chase Peeler
chasepee...@gmail.com
On Thu, Sep 12, 2019 at 10:13 AM Olumide Samson
wrote:
>
>
> On Thu, Sep 12, 2019, 2:59 PM Chase Peeler wrote:
>
>>
>>
>> On Thu, Sep 12, 2019 at 8:33 AM Olumide Samson
>> wrote:
>>
>>> Thanks to those who can vote, all in all I hope for a bet
ome people think
that since they like doing it like the way above, everyone should have to.
> —Claude
>
>
--
Chase Peeler
chasepee...@gmail.com
aking my prediction now - if this RFC passes, the adoption rate for
PHP 8 is going to be HORRIBLE.
> But many of us would also like the language engine to tighten up some of
> its extremely relaxed parts that do not fit in modern development
> environments and the lowest bar of the code quality
return false;
}
$i++;
So, why should I start having to do
if(!isset($i)){
$i = 0;
}
$i++;
when
$i++;
works just fine.
> Regards,
> --
> Rowan Tommins
> [IMSoP]
>
--
Chase Peeler
chasepee...@gmail.com
On Thu, Sep 12, 2019 at 10:20 AM Reindl Harald (privat)
wrote:
> see screenshot, you are the only guy on planet earth whose fukcing first
> line is part of the quote above
>
If you're going to reply to me off list, please at least be polite.
--
Chase Peeler
chasepee...@gmail.com
ompiler/parser, but also for humans. Expressing
> your intentions clearly is important - the less ambiguity the better.
>
> Regards,
> Robert Korulczyk
>
--
Chase Peeler
chasepee...@gmail.com
ge them.
> >
> > We can (and I believe should) augment them with alternative, stricter
> opt-in behaviors. But those who dream of simply changing PHP into a
> stricter language step by step should understand that this is simply not
> going to be happen. Not now, not ever.
> >
> > Zeev
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
On Thu, Sep 12, 2019 at 1:58 PM Stephen Reay
wrote:
>
> > On 13 Sep 2019, at 00:41, Chase Peeler wrote:
> >
> > On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown
> > wrote:
> >
> >> What if Java suddenly said that all properties are suddenly private, and
On Thu, Sep 12, 2019 at 1:58 PM Olumide Samson wrote:
>
>
> On Thu, Sep 12, 2019 at 6:54 PM Chase Peeler
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:33 PM Matthew Brown
>> wrote:
>>
>> > What if Java suddenly said that all properties are suddenly priva
nsidered an error, and often not even considered bad practice
>
>
> You seem to be arguing against *ever* changing something that a majority
> once thought was good, and fundamental to a given system. Lots of things
> fall into that category - restricting voting to men, segregation, etc.
>
>>
--
Chase Peeler
chasepee...@gmail.com
st people agree
> that the quality of Wordpress code and Plugins is highly debatable. I don't
> like the idea of not being able to progress because Wordpress users won't
> upgrade PHP.
>
> It's not a matter of won't upgrade, but that they can't upgrade. If
Wordpress decides to take their time supporting PHP 8, wordpress users
won't have any option but to wait on upgrading.
> Regards,
> Lynn van der Berg
>
--
Chase Peeler
chasepee...@gmail.com
nd use such methods is a practice that was
drilled into me from day one. Would that justify making such a change,
though?
--
Chase Peeler
chasepee...@gmail.com
enums, union types, variable typing, etc.
I also think it's a bit of a stretch to compare something like variable
initialization with things that denied people their basic human rights.
--
Chase Peeler
chasepee...@gmail.com
On Thu, Sep 12, 2019 at 1:39 PM Olumide Samson wrote:
>
>
> On Thu, Sep 12, 2019 at 6:22 PM Chase Peeler
> wrote:
>
>> On Thu, Sep 12, 2019 at 1:05 PM Matthew Brown
>> wrote:
>>
>> > that don't fundamentally change the language
>> >
>>
probably speak for yourself...
>
> If they want more customers(translating to revenue), they can upgrade and
> if they don't it's all up to them...
>
> On Thu, Sep 12, 2019 at 6:59 PM Mike Schinkel wrote:
>
> > > On Sep 12, 2019, at 10:37 AM, Lynn wrote:
> > >
exibility provided by PHP.
Don't force ME to write code a specific way because you aren't disciplined
enough to not write bad code without the compiler forcing you to do things
a certain way.
Of all of the justifications for this RFC I've heard, "I can't stop writing
bad code as long as I'm allowed to" has to be the worst.
--
Chase Peeler
chasepee...@gmail.com
>
> Also, I would also like to remind of this:
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
> I think some parts might have been violated multiple time in this thread.
>
>
I can take the hint. This will likely be my last post on the topic. I think
there
de variety of ways too) - we can find the good will to
> do it from a human perspective.
>
>
Exactly. I think it's telling that the majority of the rebuttals to
arguments against the RFC are to claim that we're against moving the
language forward, against BC breaks, etc. That couldn't be further from the
truth. We do want to move the language forward. We want do that by adding
to the language, and not changing it into an entirely different language.
> Zeev
>
>
> >
>
--
Chase Peeler
chasepee...@gmail.com
ot of uninitialized variables could definitely take
advantage of features like enums and union types (just to name a few). If
there were actually new, useful features that were dependent on such a
change, then I'd be much more open to the idea, if not outright in favor of
it. However, there aren't any new and useful features that are dependent on
the errors being thrown for uninitialized variables.
> Microsoft, Zend, and Red Hat have been showing that this is actually
> possible. How smart this is for the PHP progress is another story, but
> for the business it might be good to think about this also I guess:
> https://github.com/microsoft/php-src/releases
>
> So, to make some sort of a milestone with some of the versions -
> either 8 or 9 or something.
>
>
> --
> Peter Kokot
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
Chase Peeler
chasepee...@gmail.com
mplying you want hitch-free, no-modification upgrade to PHP 8
> from PHP 7.0?
>
I never said that. Here we go again with the "I guess you are against all
BC breaks" nonsense. If BC breaks are required to add new functionality,
or, have a very minimal negative impact, then I don't have a problem with
them. This is not one of those cases. It changes a fundamental aspect of
the language, an aspect that many people actually like, and it doesn't add
any new features to the language, nor is it needed to add any new features
to the language.
> If yes, follow the best practices and not suppress error notices.
>
> Just My Opinion
>
--
Chase Peeler
chasepee...@gmail.com
people or massive waste of brain effort.
>
> And I understand that this topic is about the governance of the project
> etc... just wanted to bring the attention of the group to the fact that
> even on 2/3 in certain cases compromises may be needed and this to be taken
> into account when deciding on the governance/voting process.
>
> Thank you all
>
> Vesko Kenashkov
>
--
Chase Peeler
chasepee...@gmail.com
1 - 100 of 215 matches
Mail list logo