Re: [PHP-DEV] Internals "camps"

2019-10-10 Thread Chase Peeler
compromising with the side that doesn't want to go there. > Walter > > -- > The greatest dangers to liberty lurk in insidious encroachment by men of > zeal, well-meaning but without understanding. -- Justice Louis D. > Brandeis > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Constraints and userland@

2019-10-10 Thread Chase Peeler
nd voting. I think there are many ways it could be done, but all of them would require additional time and dedication from people already putting in a lot of time and dedication to the development process itself. By keeping the review process manual, we can also easily revoke someone's > voting rights if the application turned out to be fraudulent (accepted by > mistake). > > — Benjamin > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Internals "camps"

2019-10-10 Thread Chase Peeler
be wrong, and welcome examples where we've deprecated something where the end goal wasn't removal. Assuming I'm correct though, that provides a pretty strong reason for why we wouldn't start doing it now. -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

2019-10-08 Thread Chase Peeler
that you use it to output text. cout << "Hello World"; It was SO confusing, because they also have printf which can be used to output text. I decided that c++ is obviously a garbage language and gave up. Not sure why anyone would ever use it! > -- > Stas Malyshev > smalys...

Re: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

2019-10-08 Thread Chase Peeler
> > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

2019-09-26 Thread Chase Peeler
to contribute. > Anyway, the vote is done, I said my piece and will shut up about it now, > - Chris > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

2019-09-19 Thread Chase Peeler
I've copy/pasted Kalle's email at the bottom so that I can address points made in both emails without risking someone getting distracted from the myriad of emails relating to coordination of work on PHP. On Thu, Sep 19, 2019 at 2:11 PM Mark Randall wrote: > On 19/09/2019 18:38, Chase Pee

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

2019-09-19 Thread Chase Peeler
On Thu, Sep 19, 2019 at 1:36 PM Dan Ackroyd wrote: > On Thu, 19 Sep 2019 at 18:33, Chase Peeler wrote: > > > > Would the removal votes be limited to the same people able to vote on > RFCs, > > Yes, that's correct. > > cheers > Dan > So, in other words, if

Re: [PHP-DEV] [RFC] Prevent disruptions of conversations

2019-09-19 Thread Chase Peeler
, visit: http://www.php.net/unsub.php > > Would the removal votes be limited to the same people able to vote on RFCs, or open to all list members? -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Improving productivity of internals mailing list

2019-09-18 Thread Chase Peeler
tentioned but accidental disruption people who are new to the > group are causing, and so should be handled separately. > > # Problem 4 - Senior project members aren't following our email etiquette. > > Solution: I'll post an RFC to address this. > > cheers > Dan > Ack > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Re: [VOTE] Reclassifying engine warnings

2019-09-18 Thread Chase Peeler
> > > > > Voting closes 2019-09-26. > > > > > > > > Regards, > > > > Nikita > > > > > > > > > > I just realized that I missed one notice here, because it is generated > > from > > > a different location: "Const

Re: [PHP-DEV] Evolving PHP

2019-09-18 Thread Chase Peeler
t we were OK with - which goes back to something else Zeev mentioned, which is not putting so many changes into a single RFC and/or a separate vote for each proposed change. I personally favor limiting the number of changes in an RFC because I think it's hard to focus the discussion, even if the votes are separated out. > —Claude -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Defining the PHP Group

2019-09-17 Thread Chase Peeler
ity' happening there. Putting each in a separate vote > would have likely not thoroughly solved this, but it would have probably > been a good first step, allowing more granular choice. I think that this > particular change (requiring separate votes for each change) can be done > relatively easily within our existing framework - similar to the Abolish > RFCs, if there's widespread agreement. In the context of Ben's email from > a few weeks ago, I'll defer to someone else to propose it if they think it > makes sense. > > Zeev > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] PHP's declining(?) popularity

2019-09-16 Thread Chase Peeler
On Mon, Sep 16, 2019 at 10:12 AM Benjamin Eberlei wrote: > > > On Mon, Sep 16, 2019 at 3:47 PM Chase Peeler > wrote: > >> On Sun, Sep 15, 2019 at 8:14 AM Zeev Suraski wrote: >> >> > On Sun, Sep 15, 2019 at 1:15 PM Olumide Samson >> > wrote:

Re: [PHP-DEV] PHP's declining(?) popularity

2019-09-16 Thread Chase Peeler
anguages like Python can do. If this is the case, we don't reverse the trend by making our language more syntactically or behaviorally like the other languages out there. We reverse it by supporting the features that are currently lacking, or, adding features that other languages don't have. -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Defining the PHP Group

2019-09-16 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
> > 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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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: > > >

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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 >> > >>

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Changing fundamental language behaviors

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
ome people think that since they like doing it like the way above, everyone should have to. > —Claude > > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [VOTE] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-09-12 Thread Chase Peeler
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

Re: [PHP-DEV] Bringing Peace to the Galaxy

2019-08-30 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-29 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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 > >

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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: >> > >>

Re: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-20 Thread Chase Peeler
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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

2019-08-16 Thread Chase Peeler
'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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Chase Peeler
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

Re: [PHP-DEV] Vote: Straw poll for P++ feasibility

2019-08-14 Thread Chase Peeler
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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Chase Peeler
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

Re: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Chase Peeler
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

Re: [PHP-DEV] PHP direction and governance [was: Re: [PHP-DEV] P++: FAQ]

2019-08-13 Thread Chase Peeler
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

Re: [PHP-DEV] P++: FAQ

2019-08-09 Thread Chase Peeler
Frankly I > think that's *super cool*, and a great way of balancing the prototyping > benefits of dynamic languages (which are most seen at small scale > codebases) and the robustness/safety of more refined type system (which are > most seen in larger code bases) within a single ec

Re: [PHP-DEV] Re: Bringing Peace to the Galaxy

2019-08-09 Thread Chase Peeler
union types and reflection, a method which returned one string would > > need to return an array, or just the first, and so on. > > > > A "separate" version would certainly be easier. The ability to rip out > > everything which wasn't kept would no doubt simplify a lot of t

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Chase Peeler
kfully, it's not nearly that big of a Thing for us to be concerned > about. > > We need to get rid of the display_errors ini directive as well. It definitely shouldn't default to "1" or be set to "1" in the sample files distributed with PHP. I would think this is a much greater security risk than short tags. While we're at it, we need to get rid of the ability to even set custom error handlers. If a programmer doesn't use that correctly, they could still end up exposing error messages that contain sensitive data. > Zeev > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Chase Peeler
ng them, no matter how painful that might be. That's actually an OK thing to do if the reasons for doing so justify it. I have yet to see the justification. All I've seen is people attempt to mitigate the cost of the break, or, say the cost doesn't really matter. > -- > Arvīds Godjuks > > +371 26 851 664 > arvids.godj...@gmail.com > Skype: psihius > Telegram: @psihius https://t.me/psihius > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Chase Peeler
On Thu, Aug 8, 2019 at 10:42 AM Peter Kokot wrote: > Hello, > > On Thu, 8 Aug 2019 at 16:17, Chase Peeler wrote: > > > > On Thu, Aug 8, 2019 at 9:35 AM Zeev Suraski wrote: > > > > > On Thu, Aug 8, 2019 at 3:17 PM Brent wrote: > > > > > &

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Chase Peeler
yet to see anyone give an actual example where they have been negatively impacted by their existence. I've given you my personal story of how removing them will negatively impact my company. I welcome anyone that can provide an actual incident where the existence of short tags hurt them, or, the continued existence is likely to have a large negative impact on them in the future. > Zeev > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-07 Thread Chase Peeler
o upgrade would be so high that it's likely I would never get approval from my superiors to spend that much time on it. > I don't have a vote, but if I were I would vote "yes". Instead, I encourage > "no"-voters to reconsider, and others to vote "yes" too :) > > Cheers, > Nicolas > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-07 Thread Chase Peeler
On Wed, Aug 7, 2019 at 1:00 PM Peter Kokot wrote: > Hello. > > On Wed, 7 Aug 2019 at 18:56, Chase Peeler wrote: > > > > > > > > On Wed, Aug 7, 2019 at 12:45 PM Peter Kokot > wrote: > >> > >> On Wed, 7 Aug 2019 at 16:14, Zeev Suraski wrote

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-07 Thread Chase Peeler
passes, then it will be implemented as proposed. If it fails, then treatment of short tags will remain as it currently is. I hope you will reconsider your decision to not vote on this new RFC. I understand your concerns. As someone that didn't like the outcome of the first vote either, I also didn't feel that a revote just because a lot of people decided to speak up after the fact was the correct course of action. I don't think that is what is happening here, though. -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-06 Thread Chase Peeler
On Tue, Aug 6, 2019 at 1:19 PM G. P. B. wrote: > > > > On Tue, 6 Aug 2019 at 19:12, Rowan Collins > wrote: > >> On Tue, 6 Aug 2019 at 17:59, Chase Peeler wrote: >> >> > I'm not a voter, but, I have a question. If this fails, does that mean >&g

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-06 Thread Chase Peeler
> Best regards > > George P. Banyard > > [1] https://wiki.php.net/rfc/deprecate_php_short_tags_v2 > -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

2019-07-24 Thread Chase Peeler
ink this RFC handles the deprecation process much better. My objections to the previous RFC were two-fold: 1.) benefits didn't outweigh harms and 2.) deprecation/removal path was dangerous and harmful. I still think #1 applies to this RFC. I do not think #2 does. While I agree with some others that the it might be better to postpone the decision about the ultimate removal to a later date, I don't think slating it for 9.0 is that big of a deal. I think it also gives people much more time to adapt than previous road maps. -- Chase Peeler chasepee...@gmail.com

Re: [PHP-DEV] Error instead of returning false

2019-05-07 Thread Chase Peeler
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

Re: [PHP-DEV] Alternative approach to short tags deprecation

2019-04-25 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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 : > > > >

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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 &

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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:

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Chase Peeler
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

Re: [PHP-DEV] Re: PHP (ext/interbase) driver maintenance

2019-04-16 Thread Chase Peeler
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

Re: [PHP-DEV] RFC Process: more productive conversations

2019-03-26 Thread Chase Peeler
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

Re: [PHP-DEV] bool values and increment operators?

2019-03-25 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Deprecate PHP's short open tags

2019-03-25 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Abolish Short Votes

2019-03-22 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] Arrow functions / short closures

2019-03-13 Thread Chase Peeler
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

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-12 Thread Chase Peeler
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

Re: [PHP-DEV] RFC Draft: Comprehensions

2019-03-12 Thread Chase Peeler
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

Re: [PHP-DEV] print with newline

2019-03-06 Thread Chase Peeler
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

Re: [PHP-DEV] Variadic is_*() functions

2019-02-11 Thread Chase Peeler
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 >

Re: [PHP-DEV] Variadic is_*() functions

2019-02-11 Thread Chase Peeler
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:

Re: [PHP-DEV] [VOTE] Making stdClass iterable

2019-02-06 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] JIT

2019-01-31 Thread Chase Peeler
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

Re: [PHP-DEV] RFC: RFC Workflow & Voting (2019 update)

2019-01-31 Thread Chase Peeler
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

Re: [PHP-DEV] [RFC] FFI - Foreign Function Interface

2018-12-13 Thread Chase Peeler
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

  1   2   >