[PHP-DEV] Re: RFC proposal: worker mode primitives for SAPIs

> Le 4 janv. 2024 à 18:21, Joanhey a écrit : > > Hi, > > I like it for start a discussion, than it's necessary. > But we need to see the big picture. > > The CLI-SAPI is the poor brother in PHP (contrary to other languages), but > that is another discussion than I'll try to open later. >

[PHP-DEV] Re: RFC proposal: worker mode primitives for SAPIs

Hi, I like it for start a discussion, than it's necessary. But we need to see the big picture. The CLI-SAPI is the poor brother in PHP (contrary to other languages), but that is another discussion than I'll try to open later. Create a Worker-SAPI? First any CLI worker can't access the SAPI.

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

On 09/08/2020 18:14, Chris Riley wrote: Hi all, RFC link: https://wiki.php.net/rfc/renamed_parameters I have spent the weekend working on a final revision for this RFC to address several of the points brought up. My opinion on this RFC remains unchanged: - It would have been a reasonable

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

After sending out the email, I found out that I replied to the wrong email, nevermind... Sorry about that! Best regards, Benas On Sun, Aug 9, 2020, 8:25 PM Benas IML wrote: > Hey Chris, > > thanks for the RFC but I'd like to remind you that we are already past the > feature freeze. Moreover,

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hey Chris, thanks for the RFC but I'd like to remind you that we are already past the feature freeze. Moreover, it seems that you don't have an actual implementation as well. Best regards, Benas On Sun, Aug 9, 2020, 8:15 PM Chris Riley wrote: > Hi all, > > RFC link:

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi all, RFC link: https://wiki.php.net/rfc/renamed_parameters I have spent the weekend working on a final revision for this RFC to address several of the points brought up. Specifically: - Cut down the scope of the RFC to only focus on delivering an opt in to named parameters, with the renaming

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi internals, Continuing on my response in https://externals.io/message/61#92 , and considering ways to enhance named arguments without a BC break (while minimizing the impact on application/library authors that wish for their libraries not to be used with named parameters) I was

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi Chris, On 26/07/2020 14:52, Chris Riley wrote: Thanks for the feedback so far. In light of the feedback received both here and privately, I've made 3 changes to the RFC document Firstly, a reminder of the guideline in the RFC howto that the link to the RFC should be included in replies,

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

On Sun, Jul 26, 2020 at 3:52 PM Chris Riley wrote: > Hi all, > > Thanks for the feedback so far. In light of the feedback received both here > and privately, I've made 3 changes to the RFC document: > > 1. The original option 1, allowing renaming parameters but not requiring an > explicit opt in

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi Chris Riley, I agree with Rowan Tommin's arguments in https://externals.io/message/61#79 - I wanted named parameters by default. Miscellaneous comments: 1. https://wiki.php.net/rfc/renamed_parameters should be moved to "In Discussion" on https://wiki.php.net/rfc/ 2. I think that

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi all, Thanks for the feedback so far. In light of the feedback received both here and privately, I've made 3 changes to the RFC document: 1. The original option 1, allowing renaming parameters but not requiring an explicit opt in to enable them to be called by name has been dropped. The

Re: [PHP-DEV] Re: [RFC][Proposal] Renamed parameters

On Fri, Jul 24, 2020 at 4:00 PM Chris Riley wrote: > Hi all, > > Following up from this I've created a draft RFC: > https://wiki.php.net/rfc/renamed_parameters will move to in discussion > once > I've ensured everything important has been captured. > > Regards, > Chris > You added PHP 8.0 as a

[PHP-DEV] Re: [RFC][Proposal] Renamed parameters

Hi all, Following up from this I've created a draft RFC: https://wiki.php.net/rfc/renamed_parameters will move to in discussion once I've ensured everything important has been captured. Regards, Chris On Fri, 24 Jul 2020 at 12:12, Chris Riley wrote: > Hi all, > > The named parameters RFC has

[PHP-DEV] Re: RFC Proposal: Make the hash extension always available

Den tir. 4. sep. 2018 kl. 12.20 skrev Christoph M. Becker : > That appears to be sensible. Anyhow, *if* we do this, we also should > move the MD5, SHA1 and CRC32 code from ext/standard to ext/hash (MD5 and > SHA1 is currently dead code in ext/hash, and the CRC32 implementation > seems to be

[PHP-DEV] Re: RFC Proposal: Make the hash extension always available

On 04.09.2018 at 11:11, Kalle Sommer Nielsen wrote: > I just posted an RFC and set it up for discussion[1], this proposes to > make the ext/hash extension always enabled, similar to that for date, > spl & pcre. > > Comments are welcome. I intend to start voting in 2-3 weeks time, > should there

Re: [PHP-DEV] Re: RFC Proposal

I'd be fine with throwing exceptions in PHP 7.4, but maybe a warning in PHP 7.4 and an exception in 8.0 then? Things like that can be a pretty stupid error that doesn't get noticed, and there are probably not many use cases checking the return to be false and then not throwing an exception.

[PHP-DEV] Re: RFC Proposal

On 10.08.2018 at 22:15, Jesse G. Donat wrote: > I'm measuring reaction for an RFC > > Essentially right now preg regex's fail silently - and you have to > actually check them manually with preg_last_error - something I've > never actually seen done in code. > > see: > >

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

2016-04-12 18:36 GMT+03:00 Midori Koçak : > what is sugar? > Here is a description: https://en.wikipedia.org/wiki/Syntactic_sugar But my proposal, almost not realistic implement, although I may be mistaken... ;) -- PHP Internals - PHP Runtime Development Mailing List To

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

what is sugar? On Monday, 11 April 2016, S.A.N wrote: > Maybe even more sugar? :) > > > class SugarCache > { > // Methode getValueFromDB() called, if its value null > public $value ??= $this->getValueFromDB(); > > // Methode getValueFromDB() called, if $value not

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

Maybe even more sugar? :) getValueFromDB(); // Methode getValueFromDB() called, if $value not transmitted or null value public function __construct($value ??= $this->getValueFromDB()) { //... } public function getFromCache() { // Methode getValueFromDB() called, once upon init static

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

Thank you! I just thought it might have been possible to change the text between the tags on the RFC page. Good luck with the voting! Regards //Björn Den 2016-03-30 kl. 22:25, skrev Midori Kocak: Thank you, I removed ‘equal’, you were right. I could not find a way to change url. Also voting

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

Thank you, I removed ‘equal’, you were right. I could not find a way to change url. Also voting is already started. Midori > On 30 Mar 2016, at 22:22, Björn Larsson wrote: > > Hi, > > Think the word equal should be removed from RFC name so > it becomes "Null

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

thank you so much. I updated the name. On Thursday, 24 March 2016, Andrea Faulds wrote: > Hi Midori, > > Midori Kocak wrote: > >> Hi, >> >> I changed the name but I really don’ know how to change the url :) >> >> Midori >> >> > I don't think you can change the URL. In the past I've

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

Hi Midori, Midori Kocak wrote: Hi, I changed the name but I really don’ know how to change the url :) Midori I don't think you can change the URL. In the past I've seen people create a new page in the /rfc/ namespace, copy the content there, and edit the old page to point to the new one.

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

Hi, I changed the name but I really don’ know how to change the url :) Midori > On 24 Mar 2016, at 21:35, Andrea Faulds wrote: > > Hi, > > Sara Golemon wrote: >> Changing "equal" to "assignment" seems to have been the suggestion. >> I've taken that into the short-ternary

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

Hi, Sara Golemon wrote: Changing "equal" to "assignment" seems to have been the suggestion. I've taken that into the short-ternary version. And as a minor edit (not worth closing/reopening vote) would recommend the same for null coallesce. -Sara The other suggestion was to change "coalesce"

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

Changing "equal" to "assignment" seems to have been the suggestion. I've taken that into the short-ternary version. And as a minor edit (not worth closing/reopening vote) would recommend the same for null coallesce. -Sara On Thu, Mar 24, 2016 at 8:46 AM, Midori Kocak wrote:

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

there were no suggestions. Do you have one? > On 24 Mar 2016, at 16:36, Björn Larsson wrote: > > Den 2016-03-13 kl. 02:59, skrev Andrea Faulds: >> Hi Midori, >> >> Midori Kocak wrote: >>> Forgive my rookieness and let me introduce my first RFC here: >>>

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

Couldn't agree more :) //Björn Den 2016-03-24 kl. 16:49, skrev Sara Golemon: Changing "equal" to "assignment" seems to have been the suggestion. I've taken that into the short-ternary version. And as a minor edit (not worth closing/reopening vote) would recommend the same for null coallesce.

Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution timepolymorphic methods

On 3/22/16 1:34 PM, Stephen Coakley wrote: On 03/21/2016 11:09 PM, Levi Morrison wrote: This requires you to query state with `isSome()`. This is hardly any different from a null case, just more code. We can already accurately distinguish between `null` and another value. If we want an option

Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution timepolymorphic methods

On 03/21/2016 11:09 PM, Levi Morrison wrote: This requires you to query state with `isSome()`. This is hardly any different from a null case, just more code. We can already accurately distinguish between `null` and another value. If we want an option for safer PHP code I think we need a safer

Re: [PHP-DEV] Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On Mon, Mar 21, 2016 at 5:03 PM, Stephen Coakley wrote: > On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: >> >> So I want to "return a NULL". I want to express uncertainty, a >> nonexistence. But I want to express that I will return something. And I >> want to

[PHP-DEV] Re: RFC Proposal: Maybe monad and execution time polymorphic methods

On 03/21/2016 03:04 PM, Facundo Martinez Correa wrote: So I want to "return a NULL". I want to express uncertainty, a nonexistence. But I want to express that I will return something. And I want to have this NULL checking at interpretation time. I want everything, and none of the drawbacks. As

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

Hi Midori, Midori Kocak wrote: Forgive my rookieness and let me introduce my first RFC here: https://wiki.php.net/rfc/null_coalesce_equal_operator I think this is a reasonable proposal. I had foreseen that we might add a ??= operator

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

On Fri, Feb 19, 2016 at 7:59 AM, Zeev Suraski wrote: >> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote: >> >> Hi all, >> >>> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote: >>> >>> Colin O'Dell wrote: I'd like to propose an RFC to

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

> > By the time of 8.0 nothing would be different from today. 8.0 is not > some magic number by which old code ceases to exist. > The usage of "var" may continue to decline as folks increasingly adopt the newer visibility keywords. Perhaps it's too early to make this decision and this discussion

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

> > It would have to be done in 8.0, since removing it would constitute a BC > break. > Thanks for clarifying that Tom! Makes sense to me. > It's worth noting that there were better reasons for deprecating PHP > 4-style constructors over the simple redundancy argument. Specifically, > there was

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

Hi! > But is there a strong reason to keep it forever, especially considering its Yes. It's the same reason - "no reason to remove". When we have action which on one hand has no tangible benefit and on the other hand has tangible harm, we should not do it. > decline in usage? Perhaps by

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

> > I think it's a drop in the bucket compare to new features we're adding > plenty of on every version. These make the language a lot more complex > than var being an alias to public (not even different syntax). > Very true. I'm not proposing this because it's a great new feature. But has this

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

Hi! > I do have a general question about these types of changes: if the > deprecation were to land in 7.1, when would the actual removal take place - > 7.2 or 8.0? Or would that be a voting option? It would have to be done in 8.0, since removing it would constitute a BC break. It's worth noting

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

> On 18 בפבר׳ 2016, at 23:23, Yasuo Ohgaki wrote: > > Hi all, > >> On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote: >> >> Colin O'Dell wrote: >>> >>> I'd like to propose an RFC to deprecate and eventually remove the "var" >>> keyword. >> >> >> I don't

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

> Though if we do get rid of the var syntax, I'd like it if we kept the > reserved word, because it still might be useful in future for typed > variables or different variable scoping. Good idea Andrea! Thanks for that suggestion. I do have a general question about these types of changes: if

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

Hi all, On Fri, Feb 19, 2016 at 4:33 AM, Andrea Faulds wrote: > > Colin O'Dell wrote: >> >> I'd like to propose an RFC to deprecate and eventually remove the "var" >> keyword. > > > I don't have a strong opinion on that, I guess I'm in favour. It seems like > a fairly harmless

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

Hi Colin, Colin O'Dell wrote: I'd like to propose an RFC to deprecate and eventually remove the "var" keyword. I don't have a strong opinion on that, I guess I'm in favour. It seems like a fairly harmless deprecation. Though if we do get rid of the var syntax, I'd like it if we kept the

[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.

Thanks after seeing a PR with the correct wording, I finally understood what I needed to put in that last field. I feel like a robot. Also my wiki username for the internals list is: cminick Thanks for your help! On Tue, Mar 17, 2015 at 5:21 PM, Christoph Becker cmbecke...@gmx.de wrote: Admin

[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.

Admin Admin wrote: You have to enter the email address of this mailing list into the fourth field of the form. Just gave that a try, no error message. still goes back to the form. Indeed there is a bug with regard to the messages. I have submitted a PR

[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.

Admin Admin wrote: first of all https://wiki.php.net/start?do=register seems broken, the form submit just returns to the form. You have to enter the email address of this mailing list into the fourth field of the form. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development

[PHP-DEV] Re: RFC proposal, deprecate String conversion for undefined constants.

You have to enter the email address of this mailing list into the fourth field of the form. Just gave that a try, no error message. still goes back to the form. On Sun, Mar 15, 2015 at 5:01 PM, Christoph Becker cmbecke...@gmx.de wrote: Admin Admin wrote: first of all