Re: [PHP-DEV] RFC Proposal - Types for Inline Variables
Hi there, I am not a core PHP language developer, just a regular PHP programmer, and cannot speak for the whole community, so I'll just share my opinion. I believe a new language feature suggestion should contain not only its description, but also motivation: i.e. what are we trying to achieve with it. Will the development experience be worse without it, or maybe it disallows some sneaky bugs to appear in your code, or maybe it acts as a native documentation for your code etc. Personally it's hard for me to see what kind of improvement will restricting a type of a variable bring. It may prevent repurposing the variable with the same name for a different use somewhere down the function, which can lead to bugs if a function is large enough. However, for such cases I think better idea would be to introduce `const` variables like in JavaScript - which can only be set once and cannot be reassigned later. This way you'll also guarantee the type of the variable will be preserved. > We can add types in a lot of places, but we still don't have a way to add types to inline variables. > int $value = 10; > $value = 'foo'; // TypeError Can you describe some use cases where this feature will be useful? I see it's coming from statically typed / compiled languages like C++, but in such languages compiler must know variable type in order to manage memory properly. As PHP is an interpreted language, it doesn't have this problem. Regards, Illia / someniatko
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Dan, On Sat, Feb 4, 2023 at 8:34 AM Dan Ackroyd wrote: > Hi Mark, > > On Sat, 4 Feb 2023 at 00:22, Mark Niebergall > wrote: > > > > This is also a bigger policy question for other seemingly-abandoned > > RFCs. If it is agreed that a new RFC should be created in this scenario, > > I've added some notes on the page https://wiki.php.net/rfc/howto > > I had some words already prepared from something I will post > separately, but may as well post here also: > > Mailing list etiquette - > https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list.md > > Mailing list etiquette for young'uns - > > https://github.com/Danack/RfcCodex/blob/master/etiquette/mailing_list_for_younguns.md > > RFC attitudes - > https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_attitudes.md > > RFC etiquette - > https://github.com/Danack/RfcCodex/blob/master/etiquette/rfc_etiquette.md > > Most of the stuff in there is just etiquette rather than rules, so > probably isn't appropriate for the wiki. > > Thanks, these are actually very helpful and insightful. > > > I did leave Benas as an author to give him credit for the work he did. > > Although well intentioned, that's probably quite a no-no. Putting > someone's name on something they don't necessarily agree with is > likely to cause drama. I've added a note on that also. > > > With the reverting, valuable community input was dismissed. An effort > should > > be made to address applicable previous community input instead of just > > reverting it out. > > Probably not. > > It's up to other people to persuade RFC authors why something should > be included, rather than RFC authors having to take time and energy to > justify why they are reverting unapproved edits to their RFC. > > But yep, if you want to do it as part of a separate RFC, go for it. > I'll be doing that as a separate RFC, after the typed constants RFC settles. > > cheers > Dan > Ack >
Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
Benas, On Sun, Feb 5, 2023 at 9:29 AM Benas IML wrote: > [copy of the email that I have accidentally sent to Mark individually] > > Hey, > > As much as I appreciate your enthusiasm and ideas, adding your name on > my original RFC and editing its contents without my approval is not > acceptable. Especially considering that contents of the RFCs are a > direct representation of my stance and views on a particular feature. > As such, I would not like to have my name put on proposals that I have > never discussed nor proposed myself. In this case, I explicitly have > given Máté permission to continue working on this RFC and in taking it > under his wing. > My apologies. Good luck on the RFC. > > That being said, feel free to open a new RFC yourself and copy the > contents of your previous proposal from the wiki's history tab. > I will be doing that. I'll give the typed constants RFC time to settle first. > > Best regards, > Benas > > P.S.: Next time, try also contacting me over Room 11 or GitHub, given > that I rarely check this email. > > Thanks for the updated contact information. > On Sat, 4 Feb 2023 at 02:22, Mark Niebergall > wrote: > > > > Máté, Benas, Internals, > > > > On Fri, Feb 3, 2023 at 7:34 AM Máté Kocsis > wrote: > > > > > Hi Alexandru, Mark, > > > > > > > > > > 1. Why is object type not supported? I can't see a real reason and > also > > > > there is no explanation why. > > > > > > > > > > Sorry for this, mentioning object as unsupported was an artifact from > the > > > original version of the RFC which > > > was created back then when constants couldn't be objects. After your > > > comments, I removed the object type > > > from the list. Thank you for catching this issue! > > > > > > > > > > 2. In the examples for illegal values, it would be good to explain > why > > > > they are not legal. > > > > I don't understand why "public const ?Foo M = null;" wouldn't be > legal. > > > > I think "?Foo" should work the same as "Foo|null" that would be > legal. > > > > > > > > It was there due to the same reason as above. I removed this example > now. > > > > > > I had updated the RFC page, but it looks like the changes were > reverted in > > > > December 2022. The updated version I was working on was: > > > > https://wiki.php.net/rfc/typed_class_constants?rev=1648644637 > > > > > > > > > Yeah, the original author of the RFC was surprised to find your > changes in > > > his RFC ( > https://github.com/php/php-src/pull/5815#issuecomment-1356049048 > > > ), > > > so he restored his original version. > > > Next time, please either consult with the author of an RFC if you > intend to > > > modify the wording, or you can simply create a brand new RFC - even if > it's > > > very similar to the original one (just don't > > > forget to add proper references). > > > > > > > See https://externals.io/message/117406#117460 about contact attempts > that > > were made (with no response), and other discussions about why I used the > > existing RFC instead of creating a new one. Next time I will just start a > > new RFC if an author is non-responsive. This is also a bigger policy > > question for other seemingly-abandoned RFCs. If it is agreed that a new > RFC > > should be created in this scenario, I will update > > https://wiki.php.net/rfc/howto since that scenario is not specifically > > covered. > > > > That being said, the RFC was discussed publicly actively last year, and > the > > RFC was revised based on the public input. With the reverting, valuable > > community input was dismissed. An effort should be made to address > > applicable previous community input instead of just reverting it out. > > > > I will work on a new RFC to follow this implementation to introduce > > inheritance. > > > > > > > > > > The updated RFC looks good, thanks for working on it. You may want to > > > > review the revised version I had worked on for implementation ideas, > and > > > > review the previous conversations. > > > > > > > > > > I also saw your proposal, but to be honest, I'm not that fond of the > idea. > > > This doesn't mean though that you shouldn't create a new RFC or an > > > implementation, as others may find it useful. If you kick off > > > the project, I'll surely try to review your work. > > > > > > > That is fine to break it apart as a future RFC. I have seen too many real > > world use cases where inheritance with typed constants would solve > > problems. See https://externals.io/message/117406#117408 for an > > explanation. Adding typed constants independently adds value, so it > should > > progress. > > > > > > > > > > Regards, > > > Máté Kocsis > > > > > > > Overall, I'm happy to see that this is progressing again, thanks for > > working on it. > > > > - Mark Niebergall >
[PHP-DEV] RFC Proposal - Types for Inline Variables
Hello everyone. My name is Wendell Adriel, I work with PHP since 2009 and these last couple of days I was thinking that we have made HUGE progress with types on PHP so far. We can add types in a lot of places, but we still don't have a way to add types to inline variables. The Idea I was talking about this on Twitter with some developers and I wanted to check how's the feeling on this. I know that there's a draft RFC that mentions this in the Future Scope section: https://wiki.php.net/rfc/declare_vars But my idea is not to have the declaration of variables like that. I'm thinking on a straightforward implementation that would be like: Today we have: $value = 10; $value = 'foo'; // OK My proposal is to be able to do something like: int $value = 10; $value = 'foo'; // TypeError This typing would be optional and under the hood all current declarations would implicitly add the mixed type to the variable. So this: $value = 10; Would be interpreted as: mixed $value = 10; - Implementation I'm new to the PHP source code, but I'm looking into it and studying so I can be able to work on the implementation and not only in creating/proposing the RFC. If someone that has more experience wants to help me it would be great. - I'm happy to help with anything needed for this to happen and if someone wants to discuss further just ping me. Thanks in advance for the attention. --- Best Regards, Wendell Adriel. Software Engineer | Investor | Amateur Photographer | Musician | INFP https://wendelladriel.com
