Re: [PHP-DEV] Operator overloading for userspace objects

Would there be an RFC to push this feature(with the right handler, POC) into PHP? Or something would stop it from happening? On Wed, 29 Jan 2020, 10:20 am Nikita Popov, wrote: > On Wed, Jan 29, 2020 at 12:14 AM wrote: > > > Hello everybody, > > > > > > > > the last days I have experimented a

Re: [PHP-DEV] Adding TypeError and ValueError to count() function

Only lazy developers would complain about updating legacy code, perhaps the code itself is worthless and need not be updated. Then, what's the point of pursuing latest features or PHP version when a individual or a company can't pursue code upgrade before version update? On Tue, Jan 21, 2020,

Re: [PHP-DEV] Re: [RFC] "use global functions/consts" statement

"namespace_lookup" On Sat, Jan 18, 2020, 10:32 PM Mark Randall wrote: > On 18/01/2020 18:05, tyson andre wrote: > >which is now declare(disable_ambiguous_element_lookup=1) at the top > of a file. > > I_suspect_these_long_declares_might_get_tedious > > Can we at least agree on internals that

RE: [PHP-DEV] Warn when declaring required parameter afteroptionalone

Error(in PHP 8) after warning or deprecation in 7.xnything more preferred… --- Sent from Mail for Windows 10 From: Olumide Samson Sent: Saturday, January 11, 2020 2:42 PM To: Niklas Keller; Nikita Popov Cc: Bob Weinand; PHP internals Subject: RE: [PHP-DEV] Warn when declaring required parameter

Re: [PHP-DEV] Typed array properties V2

On Fri, Jan 17, 2020, 2:54 PM Robert Hickman wrote: > > So essentially we are talking about generics. I think it's the best time > to > > do so... Maybe our wishes come true soon? ;) > > > > Given that the general trend is towards making PHP more statically > typed and very java/C# like, why not

RE: [PHP-DEV] Who are the current eligible voters?

From: Mike Schinkel Sent: Wednesday, January 15, 2020 9:23 PM To: Nikita Popov Cc: PHP Internals List Subject: Re: [PHP-DEV] Who are the current eligible voters? > On Jan 15, 2020, at 3:15 PM, Nikita Popov wrote: > > Based on master.php.net data, the number of people who are eligible for > voti

RE: [PHP-DEV] Warn when declaring required parameter after optionalone

Should it be a warning or an error? --- Sent from Mail for Windows 10 From: Niklas Keller Sent: Saturday, January 11, 2020 2:35 PM To: Nikita Popov Cc: Bob Weinand; PHP internals Subject: Re: [PHP-DEV] Warn when declaring required parameter after optionalone Hi Nikita, while this is a rather sma

Re: [PHP-DEV] Bump required libcurl version to 7.17.1

Why not the most recent and stable version? I'm thinking modern version has many bugs fixed and many vulnerabilities fixed, even with improvements that make things more faster and lighter... Just My thoughts. On Sat, Jan 11, 2020, 1:55 AM Pierre Joye wrote: > Good morning Christoph, > > I woul

Re: [PHP-DEV] exit() via exception

I'm thinking exit() shouldn't be catchable to maintain status quo, and it should be focused on the reason it was suggested(Unwinding stacks and cleaning up memories instead of longjmp'ing to shutdown). If there's any need to catch it's exception, that can be handled later through maybe a RFC discu

Re: [PHP-DEV] Warning for "confusable" types

On Fri, Oct 11, 2019, 6:47 PM Larry Garfield wrote: > On Fri, Oct 11, 2019, at 8:54 AM, Nikita Popov wrote: > > Hi internals, > > > > Something I've seen play out a couple of times: Newbies try to use > > something like "integer" or "resource" as a type, and then get a > confusing > > error messa

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

On Fri, Oct 11, 2019, 9:29 AM Benjamin Morel wrote: > > > > As people have expressed interest in hearing about direct technical > > benefits that these kinds of changes have ... let me give you an example > > that came up yesterday. > > > > Too bad this example comes after the vote has been made,

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

On Thu, Oct 10, 2019, 4:35 AM Stanislav Malyshev wrote: > Hi! > > > it into some kind of proxy war. Yes, "it breaks backwards compatibility > for > > questionable benefit" is an argument against this proposal, it is even a > > *very good* argument against it, but it's also no mandate to shut down

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

On Wed, Oct 9, 2019, 3:41 PM Bishop Bettini wrote: > On Mon, Oct 7, 2019 at 5:21 PM Olumide Samson > wrote: > >> On Mon, Oct 7, 2019, 9:20 PM Claude Pache wrote: >> >> > > Le 7 oct. 2019 à 22:06, Olumide Samson a >> écrit : >> > > >> &g

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

On Wed, Oct 9, 2019, 12:59 AM M. W. Moe wrote: > Hello, > > the point Stanislav is really not about whom; that's about thinking, work, > effort, personal walk thru a problem; > and I am sorry he is fully right; live example: > > "I think that's been inconsistencies from the part of early contribu

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

On Tue, Oct 8, 2019, 3:30 PM Chase Peeler wrote: > On Sun, Oct 6, 2019 at 9:18 AM Reinis Rozitis wrote: > > > > -Original Message----- > > > From: Olumide Samson [mailto:oludons...@gmail.com] > > > > > > it should be deprecated for exec usage since

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

On Mon, Oct 7, 2019, 9:20 PM Claude Pache wrote: > > > Le 7 oct. 2019 à 22:06, Olumide Samson a écrit : > > > > > > What's the goal of PHP? > > One important goal is (like many programming languages) to get work done. > > —Claude > I disagree, co

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

On Mon, Oct 7, 2019, 7:53 PM Stanislav Malyshev wrote: > Hi! > > > That is the purpose of the eventual vote, is it not? To allow the > > community to make that determination. > > Not exactly - there should be a good reason before the RFC comes to a > vote. If you're not sure there's a VERY good r

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

I think something that deals with system commands should be highly obvious and should not be allowed through shortcut syntax that made it easy to be hidden amongst codes for many security reasons. There's already a popular way without hidden syntax and which speaks of itself in a verifiable way ca

[PHP-DEV] Within 2 weeks, everything In PHP internals questioned

Hi Zeev, Not trying to be a distraction(I shouldn't even have messaged), but I guess you might be waking everyone up to some facts these recent days(probably in the wrong way, and to some; positive). Why did i write this? I've been following closely lately and have seen you(Zeev Suraski) questio

Re: [PHP-DEV] Defining the PHP Group

I don't think there is a valid way to define "fundamental BC breaks" or "mere BC breaks", all votes will always be a reasonable vote as much as there are people to vote on it. Whats special or different about BC break that would require slim margin or consensus votes on where this is dealing with

Re: [PHP-DEV] Defining the PHP Group

On Sun, Sep 15, 2019, 11:41 PM Olumide Samson wrote: > > > On Sun, Sep 15, 2019, 8:33 PM Stanislav Malyshev > wrote: > >> Hi! >> >> > Does anyone object to any of those words ? >> >> Yes. I do not think precommitting to implement anything that

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

Facebook launched Hack as an alternative for PHP because it was not scalable. And after that, JavaScript, TypeScript and Python became the linguas franca for web development" On Sun, Sep 15, 2019, 8:18 AM Zeev Suraski wrote: > > > On Sun, Sep 15, 2019 at 6:33 AM Mike Schinkel > wr

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

https://jaxenter.com/php-tiobe-sept-2019-162096.html I think this is one of those things we get from voting no... I might be wrong anyways :-? On Sat, Sep 14, 2019, 12:43 AM Kosit Supanyo wrote: > Hi internals > > This maybe a little bit late but I would like to propose alternative to > this RF

Re: [PHP-DEV] Evolving PHP

On Fri, Sep 13, 2019, 3:10 PM Rasmus Lerdorf wrote: > Lots of drama on internals lately. Not that different from 15-20 years ago. > A couple of things to keep in mind for everyone. > > It is not that hard to write a tool that perfectly fits your own needs and > people who are very similar to you

Re: [PHP-DEV] Changing fundamental language behaviors

I'm thinking this thread is receiving much attention than really required. Irrespective of the left and right argument, I think everyone wants a better language, the leftist are just arguing on a very lazy fact, not that they don't see anything bad in their wrong argument they are all just trying

Re: [PHP-DEV] Changing fundamental language behaviors

language image and the rest of the PHP comunity. >> >> 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 tak

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:29 PM Chase Peeler wrote: > > > On Thu, Sep 12, 2019 at 3:17 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:11 PM Michael Babker >> wrote: >> >> > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson >> > wrote:

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:15 PM Chase Peeler wrote: > > > On Thu, Sep 12, 2019 at 3:06 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker >> wrote: >> >> > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot >> wrote: >&g

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:11 PM Michael Babker wrote: > On Thu, Sep 12, 2019 at 2:06 PM Olumide Samson > wrote: > >> On Thu, Sep 12, 2019 at 8:00 PM Michael Babker >> wrote: >> >>> On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot >>> wrote: >>

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 8:00 PM Michael Babker wrote: > On Thu, Sep 12, 2019 at 1:51 PM Peter Kokot wrote: > > > Just a dumb idea, since there clearly is a majority in favor of the > > change with these warnings and strictness and all that now... Why not > > making something like an LTS PHP 7.x

Re: [PHP-DEV] Changing fundamental language behaviors

On Thu, Sep 12, 2019 at 7:10 PM Lynn wrote: > On Thu, Sep 12, 2019 at 7:59 PM Mike Schinkel wrote: > > > > > > > Just a few weeks ago I was refactoring some particularly horrible code > > developed by previously employed developers — a code based that has a > 1400 > > line function and many othe

Re: [PHP-DEV] Changing fundamental language behaviors

I think it would do this list more good than not, if we talk or assume about some people who will ever or never upgrade... Seriously? How do you know if they would never or ever upgrade, you can only and should probably speak for yourself... If they want more customers(translating to revenue), the

Re: [PHP-DEV] Changing fundamental language behaviors

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 private, and > >> can only be accessed through getter/setter methods? > >> > > > > If Java announced that the next major

Re: [PHP-DEV] Changing fundamental language behaviors

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 > > > > > > There's clearly a big disagreement about whether this is a fundamental > > change or not. > > > > Preventing something that

Re: [PHP-DEV] [RFC] Object Initializer

The RFC is a beautiful feature suggestion, but something is telling me as beautiful and straightforward the syntax is, what can the use case be? I really love Constructor or Object initialization to be implemented in PHP, but is there something I think you're missing in the RFC? Thanks for the RF

Re: [PHP-DEV] Changing fundamental language behaviors

You first me on that reply Dan, I guess I should just say "the naysayers are back", I can see their footprint all around. The RFC is Request for Comment on any changes, is there an explicit or implicit mention about what kind of proposed changes can be made? Mr/Mrs Zeev are you for PHP or against

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

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 better language >> where >> we can proudly post jobs(even intern) for on our company'

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

Thanks to those who can vote, all in all I hope for a better language where we can proudly post jobs(even intern) for on our company's website without been looked down on as inferior. Since I can't vote, I can only hope for the best. <3 On Thu, Sep 12, 2019, 1:17 PM Nikita Popov wrote: > Hi in

Re: [PHP-DEV] Make error_reporting=E_ALL the default

+1 On Fri, Aug 30, 2019, 11:13 AM Javier Spagnoletti wrote: > Great step! +1 > Thank you so much Nikita. > > El vie., 30 de ago. de 2019 07:02, Arvids Godjuks < > arvids.godj...@gmail.com> > escribió: > > > пт, 30 авг. 2019 г. в 11:33, Nikita Popov : > > > > > Hi internals, > > > > > > Relating

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

On Thu, Aug 29, 2019, 12:33 AM Stanislav Malyshev wrote: > Hi! > > On 8/28/19 4:23 PM, Matthew Brown wrote: > > $foo++ becoming 1 when $foo is undefined is not intuitive to me. > > I guess we have different intuition. > > > To take a very trivial example, that behaviour causes “for ($i = 0; > > $

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

On Wed, Aug 28, 2019, 5: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. > > That's a challenge which a

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

Hi internals@, Figured I could contribute without the vcs account. Request canceled. Thanks, Samson. On Tue, Aug 20, 2019, 12:38 PM Olumide Samson wrote: > Hi internals@, > I'm Olumide Samson, lead developer at Zapay Inc(a financial service > provider). > > All of our backe

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

Hi internals@, I'm Olumide Samson, lead developer at Zapay Inc(a financial service provider). All of our backend codes are written majorly in PHP(which is a language i've been programming in since 2007) and C(since 2006) which i write advance sys-related programs in... I'm

Re: [PHP-DEV] Removing old branches in php-src

> > Maybe it might necessarily not need be removed, if this might be a better > idea, why shouldn't there be a php-archive or something like that as a git > account or repository where all those historical branches may be kept for > historical access? > > I think removing isn't making sense to me a

[PHP-DEV] VCS Account Request: noobshow

Contributing to the PHP Core and PHP Windows code -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

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

On Fri, Aug 16, 2019, 5:08 PM Mark Randall wrote: > On 16/08/2019 11:18, Christoph M. Becker wrote: > > It is not necessarily required to have an implementation for an RFC > > available, see item (6) in . > > I have enormous respect for Derick, but I can't help but

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

: > > > On Thu, Aug 15, 2019, 3:20 AM Olumide Samson > wrote: > >> On Thu, Aug 15, 2019, 10:52 AM Peter Kokot wrote: >> >> > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski wrote: >> > > >> > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans >

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

On Thu, Aug 15, 2019, 10:52 AM Peter Kokot wrote: > On Wed, 14 Aug 2019 at 22:41, Zeev Suraski wrote: > > > > On Wed, Aug 14, 2019 at 6:14 PM Derick Rethans wrote: > > > > > Hi, > > > > > > In the last week(s) there has been a lot of chat about Zeev's P++ idea. > > > Before we end up spending t

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

I would say, PHP needs a direction(where're we headed?) than having a split language. Seriously, the core team have *tons of kudos* from the outside world(even outside of PHP) and i think something called for those serious implementation and i believe everyone(or simply put, the majority) one day

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

On Wed, Aug 14, 2019, 5:23 PM Robert Korulczyk wrote: > > While possibly a bit hyperbolic, most of the arguments basically come > off that way to me as well. I've definitely viewed most of what you've said > in > > that manner. > > I guess we're in some kind of limbo where half of the people do n

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

On Wed, Aug 14, 2019, 11:24 AM Peter Kokot wrote: > On Wed, 14 Aug 2019, 12:09 Reinis Rozitis, wrote: > > > > It is surprising how thing that is considered by one to be a security > > risk, is treated > > > as nothing relevant by others. This dichotomy is quite disturbing - in > > what case > >

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

Not sure what the counter argument is really driving at. So, because some people are using a function or an unworthy directive, then there can't be a major change in that aspect? Many languages clean up many unused functions, directives and so more just to meet some proper standard. I'm been shamed

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

Not sure what the counter argument is really driving at. So, because some people are using a function or an unworthy directive, then there can't be a major change in that aspect? Many languages clean up many unused functions, directives and so more just to meet some proper standard. I'm been shamed