Re: [PHP-DEV] [RFC] [Discussion] Typed class constants
[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. 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. Best regards, Benas P.S.: Next time, try also contacting me over Room 11 or GitHub, given that I rarely check this email. 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Alias for `int|float`
...and introducing 'number' would also be a huge BC break (even in our codebase there's a class named 'Number'). Best regards, Benas On Sun, Nov 8, 2020, 7:26 PM Reindl Harald (privat) wrote: > > > Am 08.11.20 um 18:09 schrieb Eugene Sidelnyk: > > Hello, internals! > > > > What do you think about creating shorthand `number` for `int|float`? > > nothing because: > > a) float accepts int anyways > b) overloading the engine for each and every nuance is not helpful > c) union types are clear and readable > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] List of attributes
On Mon, Oct 19, 2020, 6:17 PM Theodore Brown wrote: > On Mon, Oct 5, 2020 at 9:24 AM Nicolas Grekas > wrote: > > >> I'm wondering if the syntax that allows for several attributes is > >> really future-proof when considering nested attributes: > >> > >> > >> *1.* > >> #[foo] > >> #[bar] > >> > >> VS > >> > >> *2.* > >> #[foo, bar] > >> > >> Add nested attributes to the mix, here are two possible ways: > >> > >> *A.* > >> #[foo( > >> #[bar] > >> )] > >> > >> or > >> > >> > >> *B.* > >> #[foo( > >> bar > >> )] > >> > >> The A. syntax is consistent with the 1. list. I feel like syntax > >> B is not desired and could be confusing from a grammar pov. > >> BUT in syntax 2., we allow an attribute to be unprefixed (bar), > >> so that syntax B is consistent with 2. > >> > >> Shouldn't we remove syntax 2. in 8.0 and consider it again when nested > >> attributes are introduced? > >> > >> I voted yes for syntax 2. when the attributes were using << >>. I would > >> vote NO now with the new syntax. > >> > >> Nicolas > > > > As far as my understanding goes, if we introduce "nested" attributes, it > > will be in the form of relaxing constraints on constant expressions, i.e. > > by allowing you to write #[Attr(new NestedAttr)]. > > > > Nikita > > Back when the original `<<>>` attribute syntax was being implemented, > there was an attempt to do just this. But it turned out to be very > difficult to implement, and it was ultimately given up on since it > required significant changes to const expressions. Earlier this year > there was also a poll to gauge interest in supporting function calls > in constant expressions, but most voters opposed it. [1] > > Even if a proposal for relaxing constraints on constant expressions > gains enough support, it's not clear this is the ideal path forward > for nested attributes, since as Nicolas pointed out this wouldn't > have the same lazy-loading semantics as existing attributes. > > Straightforward support for nested attributes was one of my main > motivations for proposing the `@@` syntax in the Shorter Attribute > Syntax RFC, [2] and I had hoped to collaborate on a follow-up RFC to > support nested attributes with the AT-AT syntax. This would allow > existing nested docblock annotations such as Nicolas's example to > translate intuitively to native attributes: > > @@Assert\All([ > @@Assert\Email, > @@Assert\NotBlank, > @@Assert\Length(max: 100) > ]) > > This would also preserve the lazy-loading feature where these > attribute classes aren't loaded until code calls `newInstance` > on one of the `ReflectionAttribute` objects. > > But then the Shorter Attribute Syntax Change RFC [3] came along and > derailed this plan... > > In theory nested attributes could be supported in the same way with > the `#[]` syntax, but it's more verbose and I think less intuitive > (e.g. people may try to use the grouped syntax in this context, but > it wouldn't work). Also the combination of brackets delineating both > arrays and attributes reduces readability: > Welp, both variants seem to be readable. > #[Assert\All([ > #[Assert\Email], > #[Assert\NotBlank], > #[Assert\Length(max: 100)] > ])] > > But at this point I assume this is the most viable path forward for > nested attributes (barring another syntax re-vote and delay of PHP 8). > Are you actually kidding me? 4th revote? Please no. I know Derick and Benjamin have stated they aren't in favor of nested > attributes and didn't put any thought into the syntax for them, but I > feel this is unfortunate since nested attributes are an established > pattern with legitimate use cases in existing libraries. > > Best regards, > Theodore Best regards, Benas > > [1]: https://wiki.php.net/rfc/calls_in_constant_expressions_poll > [2]: https://wiki.php.net/rfc/shorter_attribute_syntax > [3]: https://wiki.php.net/rfc/shorter_attribute_syntax_change > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php >
Re: [PHP-DEV] Attributes on property groups
And why would we want to do that?
On Tue, Sep 22, 2020, 4:04 PM Marco Pivetta wrote:
> Probably easier/simpler to deprecate (then remove) property declaration
> groups, no?
>
> On Tue, Sep 22, 2020, 14:51 Nikita Popov wrote:
>
> > Hi internals,
> >
> > Currently, placing an attribute on property (or constant) groups is not
> > allowed:
> >
> > class Foo {
> > #[NonNegative]
> > public int $x, $y, $z;
> > }
> > // Fatal error: Cannot apply attributes to a group of properties
> >
> > This is a case that was not explicitly mentioned in the RFC and we
> decided
> > to be conversative when landing the initial implementation.
> >
> > However, this restriction seems pretty arbitrary to me, and I think we
> > should remove it. While there is some potential ambiguity as to whether
> the
> > attribute applies to all properties or only the first one, I think the
> > general expectation is that it should apply to all properties, just like
> > the property type does.
> >
> > PR to allow this: https://github.com/php/php-src/pull/6186
> >
> > Any thoughts on this?
> >
> > Regards,
> > Nikita
> >
>
Re: [PHP-DEV] Compiler Optimizations
Ah, sorry! Misread your post. Anyways, the compiler doesn't transform
`\array_keys()` yet, so there's no optimization for that.
As for other compiler optimizations, 2 that I know that the compiler does
is:
1. Binary OP evaluation i. e. `2 * 2` does not yield `ZEND_ADD` opcode but
is instead computed by the compiler directly.
2. There are special functions that have their own opcodes. You can learn
more about those here:
https://phpinternals.net/articles/optimising_internal_functions_via_new_opcode_instructions
Best regards,
Benas
On Tue, Sep 15, 2020, 4:44 PM Chase Peeler wrote:
> I wasn't proposing that my example be supported. I'm totally okay with the
> fact that it doesn't. My question was about whether or not those kinds of
> optimizations are documented anywhere so that developers can make sure they
> don't miss out on them by not fitting the proper pattern.
>
> On Tue, Sep 15, 2020 at 9:40 AM Benas IML
> wrote:
>
>> Hey,
>>
>> During my free time, I'm implementing that specific `array_keys`
>> optimization. I'm not planning on supporting cases like yours (i. e.
>> indirection through a variable) since there's no point in doing that. And
>> also, it's not feasible to support every use case. Should we also support
>> cases like this?
>>
>> ```php
>> $a = 'array_keys';
>> $b = $a(...);
>> $c = 'b';
>>
>> foreach ($$c as $key) {
>> ...
>> }
>> ```
>>
>> Obviously not. `\array_keys` optimization will work the same way as an
>> optimized `strlen` function works.
>>
>> That means that the optimization is only going to be applied if the
>> `array_keys` function is used directly in the `foreach` loop and only if a)
>> either the namespace is global b) or `\array_keys(...)`/`use function
>> array_keys` is used.
>>
>>
>> Best regards,
>> Benas
>>
>> On Tue, Sep 15, 2020, 4:23 PM Chase Peeler wrote:
>>
>>> I brought this up on another thread, but it wasn't addressed (which is
>>> fine, since it was somewhat off-topic). I thought it might be
>>> worth bringing up in its own thread, though.
>>>
>>> In the other thread, someone had mentioned the following compiler
>>> optimization
>>>
>>> foreach(\array_keys($arr) as $key) {
>>>
>>> and quietly transform that into:
>>>
>>> foreach ($arr as $key =>
>>> $_unusedVariableNameThatIsntEvenSpilledToTheScope)
>>> {
>>>
>>> I would be more likely to write:
>>> $keys = array_keys($arr);
>>> foreach($keys as $key){
>>> Which would prevent me from being able to take advantage of the
>>> optimization.
>>>
>>> So, what I was wondering, is if there are other optimizations I might be
>>> missing out on, and if so, are they documented anywhere?
>>>
>>>
>>> --
>>> Chase Peeler
>>> chasepee...@gmail.com
>>>
>>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>
Re: [PHP-DEV] Compiler Optimizations
Hey,
During my free time, I'm implementing that specific `array_keys`
optimization. I'm not planning on supporting cases like yours (i. e.
indirection through a variable) since there's no point in doing that. And
also, it's not feasible to support every use case. Should we also support
cases like this?
```php
$a = 'array_keys';
$b = $a(...);
$c = 'b';
foreach ($$c as $key) {
...
}
```
Obviously not. `\array_keys` optimization will work the same way as an
optimized `strlen` function works.
That means that the optimization is only going to be applied if the
`array_keys` function is used directly in the `foreach` loop and only if a)
either the namespace is global b) or `\array_keys(...)`/`use function
array_keys` is used.
Best regards,
Benas
On Tue, Sep 15, 2020, 4:23 PM Chase Peeler wrote:
> I brought this up on another thread, but it wasn't addressed (which is
> fine, since it was somewhat off-topic). I thought it might be
> worth bringing up in its own thread, though.
>
> In the other thread, someone had mentioned the following compiler
> optimization
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
> I would be more likely to write:
> $keys = array_keys($arr);
> foreach($keys as $key){
> Which would prevent me from being able to take advantage of the
> optimization.
>
> So, what I was wondering, is if there are other optimizations I might be
> missing out on, and if so, are they documented anywhere?
>
>
> --
> Chase Peeler
> chasepee...@gmail.com
>
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
On Thu, Sep 3, 2020, 7:05 PM Sara Golemon wrote:
> On Thu, Sep 3, 2020 at 10:35 AM David Rodrigues
> wrote:
>
> > Do you think that it could be proxied? I mean, optimize foreach
> > (array_keys()...) syntax to not call array_keys() in fact, but a
> optimized
> > version of foreach to handle key only. I don't know it opcache could do
> > that, and if it already does.
> >
> >
> I wouldn't use the word "proxied", but yes. In my mind the compiler would
> see:
>
> foreach(\array_keys($arr) as $key) {
>
> and quietly transform that into:
>
> foreach ($arr as $key => $_unusedVariableNameThatIsntEvenSpilledToTheScope)
> {
>
> Thus not iterating the array twice and creating a temporary array of key
> names.
>
Good idea; since I'm kind of bored, I'll try to implement a prototype
myself during my free time.
-Sara
>
Re: [PHP-DEV] Draft RFC: foreach iteration of keys without values
+1.
I'd also like to mention that other languages don't have any kind of
syntactic sugar/special syntax for iterating over keys. That is achieved
using a function though.
This proposal to me seems a bit like the "return if/guard" RFC i. e. I see
no value in it.
On Wed, Sep 2, 2020, 8:13 PM Nikita Popov wrote:
> On Wed, Sep 2, 2020 at 5:16 AM Mike Schinkel wrote:
>
> > This is a new thread for John Bafford's RFC which he mentioned on another
> > thread, see below:
> >
> > https://wiki.php.net/rfc/foreach_void <
> > https://wiki.php.net/rfc/foreach_void>
> >
>
> Just like the first time this was discussed, I don't think this RFC makes a
> sufficient case on why we need explicit syntax for this. Just ignoring the
> value is an existing pattern that works across all PHP versions:
>
> foreach ($iterable as $key => $_) { ... }
>
> Introducing special syntax for this has costs, both in terms of language
> complexity and in terms of implementation complexity. For example,
> implementing this feature will make foreach (whether or not the value is
> ignored) marginally slower, because we will have to explicitly distinguish
> this case. (Or alternatively, we'd have to specialize and increase VM code
> size -- it's not free in any case.)
>
> Iterating over just the keys is not a super common pattern and we already
> have a reasonable way to do it (that is imho just as clear, and actually
> more concise than the proposed "null" variant). The only potential
> advantage to a dedicated syntax that I see is that there could be iterators
> that can cheaply produce keys, but have expensive to produce values. That
> seems like an edge case of an edge case though, and is a situation where
> manually calling ->key() would be justifiable.
>
> Regards,
> Nikita
>
> > On Aug 31, 2020, at 5:50 PM, John Bafford wrote:
> > >
> > > Hi Riikka,
> > >
> > >> On Aug 31, 2020, at 14:13, Riikka Kalliomäki <
> > riikka.kalliom...@riimu.net> wrote:
> > >>
> > >> A common pattern that I've seen that could dearly use PHP internal
> > >> optimization, if possible, would be:
> > >>
> > >> foreach (array_keys($array) as $key) {
> > >> }
> > >
> > > I have a draft RFC (https://wiki.php.net/rfc/foreach_void) and patch (
> > https://github.com/jbafford/php-src/tree/foreachvoid against php 7.0, I
> > think) that helps with this, by allowing the following syntax:
> > >
> > > foreach($iterable as $key => void) { ... }
> > >
> > > This would iterate over the keys of the iterable, and does not retrieve
> > the values at all.
> > >
> > > In theory, this should be a general performance win any time one needs
> > to iterate over only the keys of an iterable, because it does not require
> > the use of an O(n) iteration and building of the array that array_keys()
> > would, plus it works on non-array types (such as generators or
> iterators).
> > It also is more performant than foreach($iterable as $key => $_) {},
> > because it omits the opcode that instructs the engine to retrieve the
> > value. (Presumably, a future direction could include using this request
> to
> > inform generators or iterators to only return keys, and not values, which
> > could further improve performance, especially if value generation is
> > expensive. But that is out of scope for this RFC.)
> > >
> > > If this is something we'd like for PHP 8.1 and there are no major
> > objections to the idea, then after 8.0 is released, I can move the RFC
> out
> > of Draft and into Under Discussion, and presuming a vote passes, I'll
> > update the patch as necessary to work against 8.0. But my time is limited
> > and I'm not willing to put further time into the code unless an RFC vote
> > passes.
> > >
> > > Thoughts anyone?
> >
> > +1 from me.
> >
> > BTW, your RFC says "Next PHP 7.x" for Proposed Version; might need to
> > update that?
> >
> > -Mike
>
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 18, 2020, 1:42 AM Andreas Leathley wrote:
> On 18.08.20 00:03, Benas IML wrote:
> > And then boo-yah, 6 months later we want to implement a cool new
> > feature to
> > attributes (a lot of examples were said before, ain't repeating myself)
> but
> > we can't :(( because there is no ending delimiter and thus, we will run
> > into parsing issues.
>
> Both @{} and @@{} would be possible as a future extension of the syntax
> and would have no BC break at all, if extending the syntax is something
> that would/should happen - just as possible suggestions.
Introducing `@@{}` would:
* be against `@@` "conciseness" ideology and would be longer than
`@[]`/`#[]`
* what's the point of creating a new syntax if we can just pick `@[]`/`#[]`?
> It is likely though that the vast majority of attribute usage will be
> quite simple (like the ones we have today with annotations: for routes,
> for validation, for ORMs), so having a simple syntax for a feature which
> is mostly used in a straightforward way does not seem that crazy.
>
"It is likely" is key here. So far, the only "positive" thing I have seen
about `@@` is smaller BC break which is albeit questionable since I was
able to find only 2 instances of a BC break for `@[]` (when searching top
Composer packages).
As for other "pros", let's be honest, no one cares that `@@` is 2
characters whereas `@[]` is 3 characters.
> And about your condescending remark of people trying to add to the
> discussion who have not "proven themselves in the PHP source code":
> Having a discussion with people who have different viewpoints seems like
> a big benefit for any project, because it is impossible to be an expert
>
At the end of the day, the so called "experts" are maintaining PHP source
code.
Having an opinion is okay but being ignorant about the issues which might
arise to the maintainers is completely unacceptable.
at C code, php-src, PHP code, all PHP frameworks, all the PHP libraries,
> and all the ways PHP is used today - yet all that can be relevant for
> language changes and the actual usage of new features, including the
> syntax.
>
Best regards,
Benas
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
On Tue, Aug 18, 2020, 1:04 AM Jakob Givoni wrote: > Hi Benas, > > On Mon, Aug 17, 2020 at 11:34 PM Benas IML > wrote: > > > > On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni wrote: > >> > >> The question is now if it's reasonable at all to change something for > >> 99% purely subjective reasons (no other substantial fact has been put > >> forward other than the VIM argument) well past feature freeze (yes I > > > > > > In the future, syntax with an ending delimiter might help us to not run > into new parsing issues like `@@` did. > > > > And yes, the future DOES indeed matter. I hate when people who don't > contribute to or maintain the php-src actively try to tell otherwise. > > I sincerely hope you're not trying to put words in my mouth. Don't be a > d*ck. > I was not referring to you specifically. But if you re-read these past 2 week discussion, most of the people being ignorant on the idea of "future parsing issues" are people, who aren't maintaining PHP. > > Again, in the future we might introduce a new feature that might make > > attributes have more complex parts than just an argument list. In this > > case, `@@` or `@:` is only going to f*** us up. > > It sounds like you want to develop a whole new language inside those > attribute blocks... Not sure that's a good idea either, because, you > No but we won't be able to implement a single new feature to attributes (besides nested attributes) since anything more complicated (e. g Benjamin's example) requires an ending delimiter. know, as they say, the future DOES indeed matter ;-) > > Regards, > Jakob >
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Tue, Aug 18, 2020, 12:56 AM Jakob Givoni wrote: > On Sun, Aug 16, 2020 at 11:36 AM Benjamin Eberlei > wrote: > > > > We have updated the RFC with all (hopefully) of the feedback from this > > discussion: > > > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > > > Most notable changes are: > > - A new section with several subsections on the benefits of a closing > > delimiter / enclosing syntax. > > - A section on grouping pro/cons > > - Inclusion of @: as per Theodores request > > > > We are looking for further feedback from the community. > > > > From the updated RFC: > > > There are multiple reasons why we believe the previous vote should be > revisited: > > Ok, bring it on! > > > At the point of the vote for @@, it was not clear that the syntax > required the namespace token RFC to be viable. > > While this is not a problem anymore, the @@ syntax might not have come > out on top if this information was known beforehand. > > If anything, this is an argument AGAINST this RFC. A "bad" decision > was taken. The problem with it was fixed. No need to change anything. > The argument comes across as disingenuous, I'm afraid. > And then boo-yah, 6 months later we want to implement a cool new feature to attributes (a lot of examples were said before, ain't repeating myself) but we can't :(( because there is no ending delimiter and thus, we will run into parsing issues. > Moving on... > > > The #[] syntax provides the benefit of forward compatibility, but this > also introduces some potential problems for PHP 7 code. > > An alternative syntax @[] was suggested to eleviate these problems which > was not previously voted on. > > Ok, let's analyze the logic here as well: #[] lost the vote. #[] would > have had some problems. Are there any What problems? Besides the BC breaks that all of the syntaxes (except `<<...>>`) have, there are no problems. syntaxes we still haven't voted > on? Yes! > Come on... > > And lastly... > > > We argue why we should strongly favor a syntax with closing delimiter to > keep consistency with other parts > > of the language and propose to use #[], @[], or the original << … >> > instead. > > This is the only part that contains logically valid arguments, albeit > most are subjective and speculative. Which is not to say it's not > worth voting on them. > But looking for actual facts, I only came across only this little cutie: > > For VIM users, the % operation to jump between opening and closing part > of declaration that would automatically work with [ and ]. > I fully expect all 3 VIM users to vote in favor of this RFC ;-) > > Ok, enough of my sarcasm - I only wish you'd put your strongest > arguments first and focused on quality over quantity. > I wish someone actually gave reasonable arguments as to why `@@` is better. Because a) no one cares if we have to type 2 or 3 characters b) `@@` does not ensure 100% safe future c) it does not decrease complexity in any way. > - Jakob > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
On Tue, Aug 18, 2020, 12:25 AM Jakob Givoni wrote: > On Sun, Aug 16, 2020 at 11:32 AM Benjamin Eberlei > wrote: > > > > On Sun, Aug 16, 2020 at 10:39 AM Jakob Givoni wrote: > >> > >> Hi Benjamin, > >> > >> I'm sorry, but I don't understand your argument. > >> It's true that annotations used to be enclosed in a docblock, but that > >> is not an argument for saying that attributes NEEDS to be enclosed in > >> a block too. > >> It's also true that attributes can be followed by many different > >> things, but still it doesn't follow that block enclosing is NECESSARY. > >> What I'm saying is that there is still no good argument for why > >> attribute block syntax is better than non-block syntax. > >> The only argument that was presented in the original RFC was not > >> convincing, and I pointed out why. > > > > Nobody says it's ultimately **necessarry** as @@ can work. > > Thanks for the clarification. This is the first time I've heard > someone from the block-delimiter camp concede that @@ is not > necessarily objectively "terrible" (as you yourself put it almost a > month ago), as it was made out to be. > > The question is now if it's reasonable at all to change something for > 99% purely subjective reasons (no other substantial fact has been put > forward other than the VIM argument) well past feature freeze (yes I > In the future, syntax with an ending delimiter might help us to not run into new parsing issues like `@@` did. And yes, the future DOES indeed matter. I hate when people who don't contribute to or maintain the php-src actively try to tell otherwise. know it's not a feature, but it's still controversial), even past the > beta3 date. And still without respect for letting the discussion phase > run its course before putting to a vote. > > May I remind everybody of a few words long ago from our release manager > Sara: > > > I'm fine with this or any syntax, but FF is 13 days away, you're going to > > have to give me something more substantial than "It maybe breaks > something > > somewhere somehow". > > > Regards the vote; I don't believe that @@ has been proven unworkable, > > however if I'm wrong about that, then the second choice selection from > the > > last vote would obviously take precedence. > > > If that's the case, then the solution still seems obvious: Defer > attributes > > to 8.1. I know a LOT of people will not be happy about that, but it's > the most > > responsible thing to do if the threat of forking up is that present and > > that dangerous. > > How did we end up here? What started with "[...] a deep sense of > unease that we collectively made the > wrong decision [...]" may have taken a turn for the worse when it > comes to confidence in the process and the community. > Or is it just me being dramatic? :-D > > All the best, > Jakob > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Mon, Aug 17, 2020, 4:07 PM Theodore Brown wrote:
> On Mon, Aug 17, 2020 at 7:11 AM Benjamin Eberlei
> wrote:
>
> > On Mon, Aug 17, 2020 at 3:06 AM Theodore Brown
> wrote:
> > > However, ending delimiters in PHP have little to do with how "complex"
> > > a syntax construct is (which is a rather loose definition, anyway).
> > > As I've pointed out before, standalone statements and declarations
> > > generally require an end symbol, but modifiers before a declaration
> > > do not. Attributes fall into the latter category, and therefore the
> > > lack of an end delimiter is consistent.
> >
> > A docblock is also a "modifier" under your declaration and it has an
> > ending symbol.
>
> The difference is that a docblock comment is also a standalone
> declaration - it's quite common to add one at the top of a file
> that doesn't modify any other declaration.
>
Doesn't matter that you can add them anywhere.
Internally, doc comments (on structural elements) are stored and handled by
Reflection the same way that attributes are.
> > The RFC gives a definition of the complexity as just a token vs a
> > set of name, arugment_list and constant expression parser rules. It
> > shows an example porting an ORM\JoinTable Attribute, which has
> > arguments, named parameter usage, complex definitions of default
> > values (Strings, arrays).
> >
> > This piece of code probably touches 10-20 parser rules.
> >
> > Most modifiers don't even have a parser rule, as they only match
> > their token.
>
> In this comparison really the only "complex" part of an attribute is
> the argument list, which already has its own start and end delimiters.
> So I don't really see the need to add another end delimiter after the
> argument list end delimiter
>
Again, in the future we might introduce a new feature that might make
attributes have more complex parts than just an argument list. In this
case, `@@` or `@:` is only going to f*** us up.
> > Types are missing indeed, and they are more complex than a simple
> > token, but less complex than attribute declarations.
> >
> > I guess the difference is that union types are new, and type
> > definitions used to be simple. Attributes however are *new* and
> > already complex, so we still have the option of always enclosing
> > them.
>
> An attribute without arguments has essentially the same complexity
> that a type declaration has always had. The only part that is more
> complex is the optional argument list, which as stated before has
> its own start/end delimiters.
>
> > > The RFC suggests a benefit of "Consistent colouring for being an
> > > end of the attribute syntax and the keywords in between can use
> > > different colors." I don't really understand this argument. How
> > > would an end delimiter change the syntax highlighting provided by
> > > IDEs?
> >
> > If you consider the three elements of an attribute declaration:
> > 1. Syntax for Attributes 2. Atttribute Name 3. Arguments then if
> > you color them in three different ways, then with an ending symbol
> > it improves the human readability to have the end be in the same
> > color [as] the beginning.
>
> I see what you mean now. Personally I don't think a differently
> colored end bracket will be particularly helpful to readability,
> though. IDEs will already highlight the argument list start/end
> delimiters, and the different coloring of an attribute name from
> whatever token follows it will ensure readability whether there is
> an argument list or not. Ultimately perspectives on readability will
> differ, though, since it's a somewhat subjective consideration.
>
> > > ## Potential Future Benefits of Enclosed Delimiter Syntax?
> > >
> > > The RFC shows an example of a potential "simpler" attribute using a
> > > string instead of a class name. I honestly have no idea what this is
> > > supposed to do or what benefit it would have over normal attributes.
> > >
> > > The concept of attributes being a class name with optional arguments
> > > has been proven over many years by its use in docblock annotations,
> > > and if there was some deficiency in what this syntax allows it seems
> > > like we would have discovered it by now.
> >
> > I agree on just the string, but a closure would make 100% sense for
> > a decorating feature. Javascript and Python "Attributes" work as
> > decorators, i.e. they get called around the decorated function.
> >
> > It is not a completely unrealistic feature to think off:
> >
> > @[fn($x) => syslog(LOG_INFO, "Called function foo with x: " . $x)]
> > function foo($message) {}
>
> As I understand it JavaScript decorators do not use anonymous
> functions for decorators like this, though. Instead you would make a
> named function and apply it with `@myFunc()` before the decorated
> function or class.
>
> Presumably we could accomplish the same thing in PHP with e.g. an
> `__invoke` method in the attribute class, without complicating the
> attribute syntax itself.
> Best regards,
> Theodore
> --
>
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
On Sat, Aug 15, 2020, 2:53 PM Björn Larsson wrote: > Den 2020-08-14 kl. 21:23, skrev Derick Rethans: > > > On Fri, 14 Aug 2020, Sara Golemon wrote: > > > >> Derick was trying to be good and meet my beta3 deadline. > > And I even got that date wrong by a week. Oops. > > > >> Fortunately, I gave him that deadline (while thinking RC1) knowing > >> some kind of bullshit like this would come up and LO AND BEHOLD here > >> we are. So the good news is that we actually have a spare two weeks. > >> On Fri, Aug 14, 2020 at 7:22 AM Theodore Brown > >> wrote: > >>> 2. Include a ranked voting option for @: and mention its pros and > >>> cons (it is equally concise as @@ with no BC break, but is somewhat > >>> harder to type). Patch link: > >>> https://github.com/theodorejb/php-src/pull/1 > >> Glancing at beberlei's reply, I do agree that @: is coming slightly > >> out of left field. However, we're using a STV system, so might as > >> well go wild with the options (within reason). HOWEVER, any option > >> included is going to need the same care applied as you outline in #3 > >> and #4 below. > > I would like to point out that as the main premise of the RFC was that > > the chosen syntax had no ending delimiter, I would say that any new > > suggested syntax should have one before I would be willing to consider > > adding it. > > I think that lack of ending delimiter is not a good enough reason to > exclude the @: syntax from the RFC and voting. Would be good to > have the community view on this in order to put this to rest! > No, the community view does not matter here. Including `@:` would go against the core values that this RFC is proposing: an attribute syntax that has an ending delimiter. > We have the @@ syntax in the voting and of course that's natural. > We have it in the voting poll since it's our current syntax; there are no other reasons. Still adding the @: option would in my eyes give a more complete > view of feasible syntax choices. The far fetched ones should not > be included of course. > Which would go against the entire premise of this RFC. If someone wants `@:`, he/she should create separate RFC. > r//Björn L > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [VOTE] Shorter Attribute Syntax Change
On Mon, Aug 10, 2020, 4:28 PM Theodore Brown wrote:
> On Mon, Aug 10, 2020 at 3:41 AM Derick Rethans wrote:
>
> > I've just opened the vote to make sure we don't make a terrible mistake
> > with using the @@ syntax for attributes:
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax_change#voting
> >
> > The first vote is a vote to say that you have an opinion about attribute
> > syntax. Make sure to read up on the discussion on the mailinglist if you
> > haven't done so yet.
>
> I voted "No", as the primary premise for this RFC is fundamentally flawed:
>
> > The main concern is that @@ has no ending symbol and it's inconsistent
> > with the language that it would be the only declaration or statement
> > in the whole language that has no ending termination symbol.
>
> As I pointed out in the discussion thread, this simply is not the case.
> Attributes are not standalone declarations or statements, but modifiers
> that always come before a declaration and add metadata to it. This
> is consistent with visibility modifiers and type declarations (which
> are not necessarily a single word):
>
> # declaration modifiers do not have end/grouping symbols like this
> @[MyAttr([1, 2])]
> [public] function foo(@[Deprecated] [int|float] $bar) {}
>
> # this is more consistent:
>
> @@MyAttr([1, 2])
> public function foo(@@Deprecated int|float $bar) {}
>
> > The second vote is an STV vote.
> >
> > In STV you SHOULD rank *all* choices, but don't pick the same one more
> > than once, as that will invalidate your vote.
> >
> > Please have a objective look at the table
> > (https://wiki.php.net/rfc/shorter_attribute_syntax_change#proposal) and
> > don't just go by asthetics.
>
> I find this table to be unfortunately incomplete. E.g. why doesn't it
> bold the number of required characters for @@, since this is one of
> its advantages? And
IMO there's literally no advantage in typing one less character. Because if
there is, let's also shorten all of our function names i. e. `strlen` to
`sl` and `gettype` to `gt`.
why is "Allows Grouping" marked as an advantage
> for the other three syntaxes? Grouping adds implementation complexity,
> leads to unnecessary diff noise, and is rarely more concise than @@ in
> real-world use cases.
>
I'd like to remind other internals that there is no "added complexity"
(unless someone is unable to understand 20 lines of code) and it's
misleading to say otherwise.
> I also find it concerning that the RFC doesn't have an example for each
> consideration showing how one syntax addresses it better than another.
> For example, the Shorter Attribute Syntax RFC showed potential nested
> attributes and how @@ would support them more cleanly, but this RFC
> fails to mention them anywhere.
Syntax choice DOES NOT affect how "cleanly" we can support nested
attributes. AFAIK simple recursion would allow to implement those with any
attribute syntax with exactly the same code.
> Finally, while the table mentions that each syntax other than <<>> has
> a BC break, I think it's just as important to consider the *size* of
> the breaking change. #[] and @[] are larger BC breaks than @@ since
> they break useful syntax:
>
> // with #[]
> #[x] code like this would break
> $val = ['new value']; #['old value'];
>
> // with @[]
> $x = @[foo(), bar()]; // this code would break
>
> Both of these are useful patterns, and I'm not convinced that breaking
> them is justified. Shouldn't there be a Backward Incompatible Changes
> section in the RFC with these examples?
>
> Best regards,
> Theodore
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
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, 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: 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 ability explicitly pushed into future
>> scope as opposed to leaving it to the RM discretion. This will allow a
>> fuller discussion on how best to support renaming going forward, be it
>> using my proposed syntax or using attributes.
>> - Focused in on the technical issues as opposed to subjective arguments
>> for/against.
>> - Added additional example of the polymorphism problem when it comes to
>> the
>> behaviour of variadics, which didn't seem to come up in the original RFC.
>> - Added resolution on dealing with the PHP standard library, as this is an
>> enhancement to the original named parameters RFC, this RFC proposes to opt
>> in the PHP standard library. There are a couple of minor changes to
>> behaviour for classes which extend built ins to make upgrading smoother.
>> - Clarified changes to reflection parameter
>> - Added alternative implementation option using attributes which will be
>> the subject of an additional voting option for those who would prefer to
>> go
>> down this route.
>>
>> I think the RFC now represents a concrete problem and solution suitable
>> for
>> voting on, but I'm going to leave discussion open for a few days in case
>> anyone has any queries on the revisions.
>>
>> Regards,
>> Chris
>>
>>
>> On Fri, 24 Jul 2020 at 12:12, Chris Riley wrote:
>>
>> > Hi all,
>> >
>> > The named parameters RFC has been accepted, despite significant
>> objections
>> > from maintainers of larger OSS projects due to the overhead it adds to
>> > maintaining backwards compatibility as it has now made method/function
>> > parameter names part of the API; a change to them would cause a BC break
>> > for any library users who decide to use the new feature.
>> >
>> > It is likely that the way this will shake out is that some maintainers
>> > will accept the additional overhead of including parameter names in
>> their
>> > BC guidelines and others will not, this leaves users unsure if they can
>> use
>> > the new feature without storing up issues in potentially minor/security
>> > releases of the libraries they use. This is not really an ideal
>> situation.
>> >
>> > More pressing a point is that the current implementation breaks object
>> > polymorphism. Consider this example (simplified from one of my
>> codebases)
>> >
>> > interface Handler {
>> > public function handle($message);
>> > }
>> >
>> > class RegistrationHandler implements Handler {
>> > public function handle($registraionCommand);
>> > }
>> >
>> > class ForgottenPasswordHandler implements Handler {
>> > public function handle($forgottenPasswordCommand);
>> > }
>> >
>> > class MessageBus {
>> > //...
>> > public function addHandler(string $message, Handler $handler) {
>> //... }
>> > public function getHandler(string $messageType): Handler { //... }
>> > public function dispatch($message)
>> > {
>> > $this->getHandler(get_class($message))->handle(message:
>> $message);
>> > }
>> > }
>> >
>> > This code breaks at run time.
>> >
>> > Proposals were made for resolutions to this issue however all of them
>> > require trade offs and could potentially break existing code.
>> >
>> > My proposal to resolve these two issues is to add the ability to rename
>> > parameters with a new syntax as follows.
>> >
>> > function callBar(Foo $internalName:externalName) {
>> > $internalName->bar();
>> > }
>> >
>> > $x = new Foo();
>> > callBar(externalName: $x);
>>
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: 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 ability explicitly pushed into future
> scope as opposed to leaving it to the RM discretion. This will allow a
> fuller discussion on how best to support renaming going forward, be it
> using my proposed syntax or using attributes.
> - Focused in on the technical issues as opposed to subjective arguments
> for/against.
> - Added additional example of the polymorphism problem when it comes to the
> behaviour of variadics, which didn't seem to come up in the original RFC.
> - Added resolution on dealing with the PHP standard library, as this is an
> enhancement to the original named parameters RFC, this RFC proposes to opt
> in the PHP standard library. There are a couple of minor changes to
> behaviour for classes which extend built ins to make upgrading smoother.
> - Clarified changes to reflection parameter
> - Added alternative implementation option using attributes which will be
> the subject of an additional voting option for those who would prefer to go
> down this route.
>
> I think the RFC now represents a concrete problem and solution suitable for
> voting on, but I'm going to leave discussion open for a few days in case
> anyone has any queries on the revisions.
>
> Regards,
> Chris
>
>
> On Fri, 24 Jul 2020 at 12:12, Chris Riley wrote:
>
> > Hi all,
> >
> > The named parameters RFC has been accepted, despite significant
> objections
> > from maintainers of larger OSS projects due to the overhead it adds to
> > maintaining backwards compatibility as it has now made method/function
> > parameter names part of the API; a change to them would cause a BC break
> > for any library users who decide to use the new feature.
> >
> > It is likely that the way this will shake out is that some maintainers
> > will accept the additional overhead of including parameter names in their
> > BC guidelines and others will not, this leaves users unsure if they can
> use
> > the new feature without storing up issues in potentially minor/security
> > releases of the libraries they use. This is not really an ideal
> situation.
> >
> > More pressing a point is that the current implementation breaks object
> > polymorphism. Consider this example (simplified from one of my codebases)
> >
> > interface Handler {
> > public function handle($message);
> > }
> >
> > class RegistrationHandler implements Handler {
> > public function handle($registraionCommand);
> > }
> >
> > class ForgottenPasswordHandler implements Handler {
> > public function handle($forgottenPasswordCommand);
> > }
> >
> > class MessageBus {
> > //...
> > public function addHandler(string $message, Handler $handler) {
> //... }
> > public function getHandler(string $messageType): Handler { //... }
> > public function dispatch($message)
> > {
> > $this->getHandler(get_class($message))->handle(message:
> $message);
> > }
> > }
> >
> > This code breaks at run time.
> >
> > Proposals were made for resolutions to this issue however all of them
> > require trade offs and could potentially break existing code.
> >
> > My proposal to resolve these two issues is to add the ability to rename
> > parameters with a new syntax as follows.
> >
> > function callBar(Foo $internalName:externalName) {
> > $internalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > This allows both the above problems to be resolved, by renaming the
> > internal parameter and keeping the external signature the same.
> >
> > I propose that the RFC would have two voting options.
> >
> > The first would be to implement it as proposed above, this would allow
> any
> > parameter to be called by name regardless of the intentions of the author
> > of the method/function and is closest to the current behaviour.
> >
> > The second option would be to use this syntax to make named parameters in
> > userland code explicitly opt in. As such an additional shortcut syntax
> > would be implemented: $: to designate a named parameter. eg
> >
> > function callBar($:externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x);
> >
> > If a parameter is not opted in, a compile time error is raised:
> >
> > function callBar($externalName) {
> > $externalName->bar();
> > }
> >
> > $x = new Foo();
> > callBar(externalName: $x); // Error: cannot call parameter $externalName
> > by name.
> >
> > There are pros and cons to this second
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
> > > This is some new complexity, even if only a small amount right now. > My question remains about how much more added complexity it will > require later if we implement extensions like nested attributes. > What? Are you actually saying that 30 lines of code add "complexity"? I think you should look more at the PHP source code before going to these nonsensical conclusions. PHP is a fully fledged language, not a "let's write the shortest code possible" competition. As for the nested attributes, you can implement those with simple recursion. You are trying to create problems here that don't exist. > Yes, PHP has historically been rather verbose in some ways. > Thankfully this has been gradually changing, with the short array > syntax added in 5.4, and more recently short arrow functions, > constructor property promotion, and the match expression having an > explicit goal to reduce verbosity. > No offense intended but saying that 1 extra character somehow adds verbosity is quite honestly, one of the stupidest things I have heard. While we at it, let's also rename other keywords: `function` to `f`, `while` to `w` and `static` to `s`. You know, to save those few extra characters. > What is the goal of the grouped attribute construct? I still haven't > received an answer about what makes it better than `@@`. > You can't compare attribute syntax against attribute feature. You better tell me why `@@` is better than `@[]` using arguments and not with "boo, I have to type 1 extra character with `@[]`". As for the grouped attributes. Why do we allow grouped properties and class constants? It's alternative code style that some might prefer. > > Aren't docblock annotations only wrapped in /** */ because they have to > be inside a comment? There is no need for this with the native > attribute syntax. To me, the `#[]` and `@[]` tokens don't at all look > similar to docblock comment boundaries, anyway. > Even more so with `@@`, which look nothing alike to docblocks. Just because docblock annotations contain the same character as attribute syntax, it doesn't magically mean "it's like docblocks". Because if so, `@[]` looks far far more like docblocks than `@@`. > Best regards, > Theodore Best regards, Benas
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
Hey Theodore,
On Thu, Aug 6, 2020, 8:05 PM Theodore Brown wrote:
> On Thu, Aug 6, 2020 at 5:24 AM Benas IML
> wrote:
>
> > On Thu, 6 Aug 2020 at 11:45, Rowan Tommins
> wrote:
> >
> > > On Thu, 6 Aug 2020 at 09:12, Benas IML
> wrote:
> > >
> > > > But by sacrificing a few very old codebases (that still use `#` not
> `//`)
> > >
> > > Do you have some basis for # only being used by "very old" codebases?
> As
> > > far as I'm aware, it's not deprecated, and while the PEAR style guide
> > > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all.
> > >
> > > I agree that it is probably rarer than //... and /*...*/ but let's
> avoid
> > > unnecessary hyperbole.
>
> > A grep search was done by someone in the mailing list in the original
> > `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going
> > to be a huge BC or not.
> >
> > Just about all of the matches were either from old codebases or from
> > old PHP 3-5 Metasploit exploits, which are about 5-15 years old.
>
> Hi Benas,
>
> You can look at the grep search here:
> https://grep.app/search?q=%23%5B[lang][0]=PHP
>
> The first BC break in the results is from an automated pentest
> framework repository which was last updated four days ago. So it
> seems like this is still code that is being used.
>
I work myself in the cybersecurity industry and I can tell you 100% that
the automated pentesting tool you're referring to isn't using any of that
`#[` code actively. In fact, over 80% of the code/exploits stored in that
repository don't work with new software/language versions.
That's the whole point - there are hundreds of scripts in numerous
different languages designed for exploiting only specific subset of
software designed for only specific versions of PHP/other languages.
By 5-15 years, I meant the exploits themselves.
Even the current Psalm static analysis tests use # to comment out an
> array:
> https://github.com/vimeo/psalm/blob/afce2dc66ff83ccad3f3a7aa26740a5eb829b2ca/tests/LanguageServer/SymbolLookupTest.php#L453
>
> Not that these individual examples are a big problem, they simply
> illustrate that hash comments are still used in current projects,
> sometimes in ways that the #[] attribute syntax would break.
>
...and that can be fixed within 5 seconds.
`#` comments were even deprecated in PHP's ini files in 5.6.
> When it comes to the @[] alternative, it's harder to grep for actual
> usages, since this string is used in virtually every email validation
> regex. In any case, code like @[foo(), bar()] would no longer work
> without putting a space between the error suppression operator and
> array (which frankly looks pretty confusing):
>
> $x =
> @ [Foo()]; // an array assignment with suppressed warnings
> @[Jit()] // an attribute
> function bar() {}
>
Same goes without saying with `@@` where `@@` means attributes and `@ @`
means double error suppression. Albeit, that is not useful.
> If there were some important language improvement that depended on
> breaking these syntaxes, maybe it would be justified. But so far I
> haven't seen such a justification.
>
> > We are playing probabilities here but at the moment, no one has said
> > any substantial argument why `@@` is better and thus, `@[...]` seems
> > like a better option in the long term.
>
> While none of our syntax options are perfect, I believe @@ has the best
> long-term tradeoffs because:
>
> - It doesn't break useful syntax
>
Fair enough.
- It is equally or more concise than grouped attributes without adding
> complexity to the parser/compiler
>
Are we really going to debate that ~30 lines of code add complexity?
- It offers a clean, simple way to support nested attributes in the
> future if we so desire
>
I'm sorry if I'm not following the conversation but what is blocking that
in `#[]`/`@[]`.
- It is conceptually closest to the docblock syntax the PHP community
> is familiar with
>
Well, if `@@` is similar to `@` (to me it isn't), we can say that `@[]` is
also similar to `@`.
- It is aligned with the attribute semantics of the majority of C
> family languages
>
In what way `#[]` or `@[]` aren't?
> Best regards,
> Theodore
Best regards,
Benas
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
A grep search was done by someone in the mailing list in the original `<<...>>` to `@@...` RFC thread when discussing whether `#[` is going to be a huge BC or not. Just about all of the matches were either from old codebases or from old PHP 3-5 Metasploit exploits, which are about 5-15 years old. Best regards, Benas P.S: I accidentally sent this to Rowan only, so forwarding this to the mailing list as well. On Thu, 6 Aug 2020 at 11:45, Rowan Tommins wrote: > > On Thu, 6 Aug 2020 at 09:12, Benas IML wrote: > > > > > But by sacrificing a few very old codebases (that still use `#` not `//`) > > > > > Do you have some basis for # only being used by "very old" codebases? As > far as I'm aware, it's not deprecated, and while the PEAR style guide > listed it as "discouraged", PSR-1 / 2 / 12 don't mention it at all. > > I agree that it is probably rarer than //... and /*...*/ but let's avoid > unnecessary hyperbole. > > Regards, > -- > Rowan Tommins > [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
On Thu, Aug 6, 2020, 10:18 AM Côme Chilliet < come.chill...@fusiondirectory.org> wrote: > Le Thu, 6 Aug 2020 07:48:05 +0100 (BST), > Derick Rethans a écrit : > > From the RFC: > > - No ending delimiter > > As said before, it does have an ending delimiter when they are arguments > since > there is the parenthesis around them. When there are no arguments I don’t > see > the benefit of an ending delimiter, it’s easy to spot the end of the word. Ending delimiter MAY help us in the future. I really, really hate all of those arguments stating "that we should care only about the present, not the future" and that even though `#[...]`/`@[...]` might bring benefits in the future, we should still choose `@@`". This shows clearly that some people are basing their views on subjective reasons rather than being objective. As far as this discussion is going, I see pro-`@@` people just saying "Arghhh, let's keep @@, it doesn't bring any benefits that other syntaxes do but we don't need them anyways, let's not speculate future". It's like saying you can either go through door A and get a free car or through door B and get the same car and **maybe**, even an additional 1,000$. We are playing probabilities here but at the moment, no one has said any substantial argument why `@@` is better and thus, `@[...]` seems like a better option in the long term. > > - Doesn't allow grouping > > I do not understand this argument, what is the point of grouping for @@? > Does grouping mean anything special for other syntaxes, or is it just to > save > keystrokes? If it is just to get a more concise syntax when there are > several > attributes, the fact that @@ do not need grouping is a pro, not a con. > No, it is not a pro. It's a matter of personal taste. You are basing your opinion on subjective views which goes against this RFC's principles - to choose a syntax that is the best based on the benefits it offers. > - No forwards compat with PHP 7 > > But no BC break either, while #[] introduces BC break. > Not true, technically speaking both `@@` and `#[]` have a BC break. Albeit `@@` has a smaller one. But by sacrificing a few very old codebases (that still use `#` not `//`), we are making sure that we won't run into any parsing problems in the future. And this is far more important. > - Not used ny another language > > @ is used by a lot of other languages, and @@ is the closest we can get in > PHP. > This is a pointless argument. `[...]`/`[[...]]` is also used by a lot of languages, `#[...]` and `@[...]` is the closest we can get to that. Heck, `@[...]` is the closest to both `@` and `[...]`. Best regards, Benas >
Re: [PHP-DEV] [RFC] Shorter Attribute Syntax Change RFC 0.2
A little nitpick but I don't think that `@@` really signals familiarity with docblocks. Nevertheless, I really like `@[...]`. I think it combines best of the both worlds (little-to-no BC breaks, ending delimiter, etc.) and also looks aesthetically pleasing. Best regards, Benas On Tue, Aug 4, 2020, 4:45 PM Derick Rethans wrote: > Hi, > > Out of Banjamin's suggestion[1], I've updated the Shorter Attribute > Syntax Change RFC to reflect that process: > > https://wiki.php.net/rfc/shorter_attribute_syntax_change > > Patches and comments welcome. > > FWIW, this has an excemption from the RM Sara as per [2]: > > > * Shorter Attribute Syntax Change > >- Joe/Derick - Please make sure this RFC moves along and reaches > > conclusion by beta3, as discussed previously. > > > cheers, > Derick > > [1] https://externals.io/message/111218#111261 > [2] https://externals.io/message/111286#111286 > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] @@Jit Attribute Considerations
`@@NoJit` sounds pretty alright to me. On Mon, Aug 3, 2020, 11:27 PM Derick Rethans wrote: > On 3 August 2020 20:20:35 BST, Benjamin Eberlei > wrote: > > >In that case maybe we should rename the attribute to @@DisableJit ? > >This > >would not clutter the global namespace with a "jit" class. > > Things with a negative name are usually a code smell. I'm not keen on a > @[disableJit] attribute name. > > cheers, > Derick > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
Just to chime in, `<<...>>` does not have any BC implications or problems with bit shift operators. On Thu, Jul 23, 2020, 6:05 PM Marcio Almada wrote: > Hi > > > On Thu, July 23 2020 at 1:26 AM Mark Randall wrote: > > > > > On 23/07/2020 02:00, Sara Golemon wrote: > > > > Regards the vote; I don't believe that @@ has been proven unworkable, > > > > however if I'm wrong about that, then the second choice selection > from the > > > > last vote would obviously take precedence. > > > > > > I don't believe the concern is that we have something unworkable > sitting > > > in front of us right now, after all if that were the case we would not > > > be needing to have this conversation as the RFC would already have been > > > rendered void. > > > > > > What we do have, is a deep sense of unease that we collectively made > the > > > wrong decision, based on, in part, incomplete information. > > > > > > While the initial block to @@ has been remedied by a larger > > > language-level change, that the problem existed at all provided a clear > > > example of the widely unforeseen challenges associated with the @@ > > > syntax and its lack of closing tags, and focused renewed attention on > > > long-term consequences which where perhaps not given enough > > > consideration during the vote. > > > > > > There has been one occurrence already, there will likely be more in the > > > future. But what specifically will they be and how severe? We likely > > > will not know until they happen. > > > > Hi Mark, > > > > I don't agree that there "will likely be more in the future". When I > > asked Nikita if he could think of any example that would end up being > > a problem, the only one he listed was a infinite parser lookahead > > requirement if a) attributes were allowed on statements and b) > > generics were implemented with curly braces instead of angle brackets. > > > > He noted that "it's unlikely we'd actually do that" and ended his > > email by saying "it is more likely than not, that we will not > > encounter any issues of that nature." [1] > > > > The @ attribute syntax has been used in other C family languages for > > years, and to my knowledge hasn't caused any problems in practice. > > > > It is actually the <<>> variant that is more likely to back us into a > > corner when it comes to future syntax like nested attributes (the RFC > > authors considered it to cross a line of unacceptable ugliness, > > and the alternative `new Attribute` syntax has technical problems). > > This may be one reason Hack is moving away from it to @. > > > > > But what we can say with reasonable confidence is we have an option > > > on the table that is technically superior > > > > I don't agree that #[] is technically superior. The implementation is > > virtually identical. The main practical difference is that hash > > comments could no longer start with a [ character, which would be > > surprising behavior and a larger BC break (there's definitely code in > > the wild using this right now). > > > > If you have a concrete example of syntax that is *likely* to cause a > > problem with @@, please share it. From my perspective, @@ is closest > > to the syntax used by the majority of C family languages for > > attributes, and thus is *least likely* to present future challenges. > > > > Best regards, > > Theodore > > > I was going to reply these same things, but you beat me to it. But just to > complement, after looking at the patches it became a bit evident that > most of the concerns being raised against @@ also work against the > other proposals. All have a certain level of BC break due to parsing > ambiguity: > > - @@ can break the silence operator when it's chained (useless anyway) > - #[...] breaks comments > - <<...>> has problems with bit shift operators > > From all these tradeoffs I'd rather compromise on breaking the useless > chaining of error suppression operators, FOR SURE. > > I have the impression most of this thread at this point is about personal > taste on what was voted rather than technical. Hopefully it's a wrong > impression. > > > > > [1]: https://externals.io/message/110568#111053 > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > Ty, > Márcio > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I have closed the vote. The RFC was declined with 34 in favor and 22 against. Best regards, Benas On Fri, Jul 3, 2020, 12:12 AM Benas IML wrote: > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas >
Re: [PHP-DEV] The @@ is terrible, are we sure we're OK with it?
Also, +1. I don't really care whether we switch back to `<<...>>` or `#[...]` but I think `@@` was a bad choice and thus, I think it would be a much more sensible decision to change the syntax again. At least for the sake of not running into new ambiguities and in order to stay more similar with other languages. On Wed, Jul 22, 2020, 3:00 PM Derick Rethans wrote: > Hi all, > > I know we've voted twice on this already, but are we really sure that > the @@ syntax is a good idea? > > - There are lots of grumbles, both on here, room 11, as well as in the > wider community (https://www.reddit.com/r/PHP/comments/hjpu79/it_is/) > - It has the distinct possibility to cause further parsing issues, akin > to what ended up happening with what Nikita is addressing at > https://wiki.php.net/rfc/namespaced_names_as_token > - There is no "end symbol" to make finding occurences easier. > - It is a syntax *no other language* uses. > - @ is never going to go away, so the possibility of @@ moving to @ is > also 0. > > Please, let's do the sensible and use the Rusty #[...] syntax. > > cheers, > Derick > > -- > PHP 7.4 Release Manager > Host of PHP Internals News: https://phpinternals.news > Like Xdebug? Consider supporting me: https://xdebug.org/support > https://derickrethans.nl | https://xdebug.org | https://dram.io > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: https://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC][DISCUSSION] Language Constructs Syntax Changes
Hey Michał, Personally, I think instead of making `declare(strict_types=1);` to look more like a constant, we should make it look more like a function. Since it seems that the named parameters RFC is going to be accepted, I think allowing for alternative `declare(strict_types: 1);` syntax would make much more sense. Best regards, Benas On Mon, Jul 13, 2020, 2:08 PM Michał Marcin Brzuchalski < michal.brzuchal...@gmail.com> wrote: > Hi Nikita, > > pon., 13 lip 2020 o 12:41 Nikita Popov napisał(a): > > > On Sun, Jul 5, 2020 at 9:36 AM Michał Marcin Brzuchalski < > > michal.brzuchal...@gmail.com> wrote: > > > >> Hi internals, > >> > >> I realise we're tight to the deadline but from my calculations, > >> this RFC should fit with 2w discussion and 2w voting before feature > >> freeze. > >> > >> The proposal is to allow two statements to skip parentheses so they > don't > >> look like expressions. > >> This goes to `declare` and `__halt_compiler`. > >> Changes have already been implemented and respective PR's are linked to > >> the > >> RFC. > >> > >> You can find the RFC at > >> https://wiki.php.net/rfc/language-constructs-syntax-changes > >> > >> There is no BC break! > >> Proposed changes only allow certain constructs to be considered valid. > >> > > > > I don't think introducing alternative syntax for declare and > halt_compiler > > is a good idea. It introduces two ways to write the same thing, without > > much benefit I can see. > > > > Your stated goal is to make it clearer that these aren't functions, but > > language constructs. I'm not sure your change helps that much: While > > "__halt_compiler()" looks like a function call, "__halt_compiler" looks > > like a constant lookup. For the declare syntax, "declare(a = 1)" is > already > > illegal syntax for functions, even with the parentheses. > > > > I can agree with "__halt_compiler;" similar to constant lookup, which > indeed does not mate it more clear. > > Regarding the second syntax for "declare" what I wanted to achieve is > reduce the number of different syntaxes and we do have quite a few in PHP. > I've noticed that the "declare" syntax is quite similar to the const > declare if you simply remove parentheses, > which therefore IMO increases readability, consider this example: > > declare strict_types = 1; > const GEAR_LIMIT = 5; > > From parser perspective, these both use const_list and only differ by a > first keyword and looks similar and present the same syntax construct. > Which currently is not true and they're both presented as a different > syntax. > > By introducing an alternative syntax I planned to deprecate the old as soon > as we could potentially do that. > I believe it'd be hard until we have ticks directive. > > Cheers, > -- > Michał Marcin Brzuchalski >
[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I have reopened the voting. It is going to close July 22nd, 2020. I have also added a "Why allow void return type on constructors/destructors?" section which I hope internals are going to read and consider before voting. Thanks! RFC: https://wiki.php.net/rfc/make_ctor_ret_void Best regards, Benas On Fri, 3 Jul 2020 at 00:12, Benas IML wrote: > > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I have updated the RFC with 2 changes: 1. Made the RFC target PHP 9.0 for enforcing `void` rules implicitly. 2. Added a secondary vote for allowing explicit `void` return type declaration. I will be opening the vote again on Wednesday (July 8th). Best regards, Benas On Fri, 3 Jul 2020 at 00:12, Benas IML wrote: > > Hey internals, > > I have opened the voting for the RFC, let's hope everything is going > to be smooth :). If you have any other questions, let me know! > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I closed the vote and will be restarting it tomorrow since the secondary vote breaks the policy (no BC breaks in minor versions). I will update the RFC and open it tomorrow (July 4th) again. Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Theodore, On Fri, 3 Jul 2020 at 19:52, Theodore Brown wrote: > > On Thu, July 2, 2020 at 4:12 PM Benas IML wrote: > > > I have opened the voting for the RFC, let's hope everything is going > > to be smooth :). If you have any other questions, let me know! > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Hi Benas, > > Thanks for your work on this. I'm in favor of deprecating the ability > to return values from constructors and destructors to align their > behavior with the documentation and how most other languages work. > > Unfortunately, the RFC doesn't provide an option to vote just for > this. Instead it only offers combining the deprecation with a new Quite honestly, this would also question why the "Ensure correct magic methods' signature" RFC was introduced in the first place since it also limited some magic methods to only having a single type (if declared) i. e. `__toString()` might only have `string` return type. > option for developers to choose whether constructors and destructors > are explicitly typed as void. > > But what will be the benefit of typing constructors/destructors as > void when this is the only allowed type, and after the deprecation > adding the type won't change anything anyway? It will lead to a > situation where some projects require the explicit type, others > require not having an explicit type, Same with the `void` return type in general. If you go onto GitHub, some projects have an explicit `: void`, others not. Every single feature is used by some group of people and isn't used by another. This is again, a rather subjective thing. ...and for more arguments, please read Larry's, Rowan's and my replies on the original discussion thread since I did go into mor edetail on this matter. > and the rest have a mishmash of > the two. This will lead to further bikeshedding in projects and > unnecessary code changes. If this was the case, we would also see a ton of tabs and spaces' mixed together in projects but we don't. > Allowing an explicit void type on constructors is also at variance > with other languages. For example, TypeScript does not allow > constructor return type declarations. [1] Nor does C# [2], nor does > Java. [3] Likewise, C++ constructors do not allow an explicit return > type [4], nor do initializers in Swift [5] and Kotlin [6]. ...and also please call constructors/destructors directly in any of those languages like you can in PHP. I. e. `$object->__construct()` and `$object->__destruct()`. Unlike in any of those languages, constructors also don't look or behave like constructors in PHP so comparing those languages with PHP doesn't make a whole lot of sense. > For these two reasons, I voted no on this RFC. I think it would be > fine to deprecate the ability to return values from constructors/ > destructors, though, and this could happen in PHP 8.1 if there isn't > time for it to land in PHP 8.0. > > Best regards, > Theodore > > [1]: > https://www.typescriptlang.org/play/?target=7=5#code/MYGwhgzhAEBiD29oG8BQ0PWPAdhALgE4Cuw+8hAFAJQBc0AbvAJYAmK6mAvqj0A > [2]: > https://www.c-sharpcorner.com/article/different-types-of-constructor-in-c-sharp/ > [3]: https://docs.oracle.com/javase/tutorial/java/javaOO/constructors.html > [4]: https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019 > [5]: https://docs.swift.org/swift-book/LanguageGuide/Initialization.html > [6]: https://kotlinlang.org/docs/reference/classes.html#constructors Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
*just let me know if that is a minor change and I'm okay with updating the RFC right now. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 6:20 PM Benas IML wrote: > Hey Zeev, > > For me it doesn't really matter if we enforce `void` rules implicitly in > PHP 8.1 or PHP 9.0. Just that we do at some point. > > Thus, I'm okay with closing the secondary vote and updating the RFC to > mention only PHP 9.0 (and not PHP 8.1). > > Best regards, > Benas Seliuginas > > On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski wrote: > >> >> > On 3 Jul 2020, at 13:27, Nikita Popov wrote: >> > >> > Now, whether this RFC actually makes a sufficient case to disregard >> policy >> > here is a different question, and at the discretion of the voters. >> >> I think this is key here (the first part, not the second). >> >> It doesn’t seem as if the RFC makes any case at all why it urgent to >> enforce this compatibility break outside of the standard policy. In fact, >> unless I’m missing something, it doesn’t attempt to tackle that question at >> all, and portrays it as a simple choice between two equal options that are >> up to personal preference. That is not the case - our standard policy is >> an outward facing contract, which we should be very wary of breaking - and >> at the very least do while taking a very informed, measured decision. >> >> We can not assume that all voters fully understand the implications of >> breaking the policy, or even that this would be breaking policy at all, >> given that it’s not even mentioned in the RFC. >> >> As such, I do think the current state of the RFC is somewhat problematic, >> and to actually consider introducing it into 8.1, the RFC requires 3 >> amendments: >> >> 1. State that per policy, if the RFC is passed - it would generally go >> into PHP 9.0. >> 2. Make the case of why the RFC author believes it’s important to do it >> in 8.1 and not wait for 9.0 per our public-facing policy. >> 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, >> despite our compatibility policy”, and turn it into a clear Yes/No question >> that clearly requires a 2/3 majority. Since technically it might be an >> issue, perhaps we can stick with the current wording, but still make it >> clear that for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. >> >> I think those are fairly minor amendments that can be done without >> restarting the vote, given where it’s at. >> >> Zeev > >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Zeev, For me it doesn't really matter if we enforce `void` rules implicitly in PHP 8.1 or PHP 9.0. Just that we do at some point. Thus, I'm okay with closing the secondary vote and updating the RFC to mention only PHP 9.0 (and not PHP 8.1). Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 6:05 PM Zeev Suraski wrote: > > > On 3 Jul 2020, at 13:27, Nikita Popov wrote: > > > > Now, whether this RFC actually makes a sufficient case to disregard > policy > > here is a different question, and at the discretion of the voters. > > I think this is key here (the first part, not the second). > > It doesn’t seem as if the RFC makes any case at all why it urgent to > enforce this compatibility break outside of the standard policy. In fact, > unless I’m missing something, it doesn’t attempt to tackle that question at > all, and portrays it as a simple choice between two equal options that are > up to personal preference. That is not the case - our standard policy is > an outward facing contract, which we should be very wary of breaking - and > at the very least do while taking a very informed, measured decision. > > We can not assume that all voters fully understand the implications of > breaking the policy, or even that this would be breaking policy at all, > given that it’s not even mentioned in the RFC. > > As such, I do think the current state of the RFC is somewhat problematic, > and to actually consider introducing it into 8.1, the RFC requires 3 > amendments: > > 1. State that per policy, if the RFC is passed - it would generally go > into PHP 9.0. > 2. Make the case of why the RFC author believes it’s important to do it > in 8.1 and not wait for 9.0 per our public-facing policy. > 3. Change the wording on the 2nd vote to “introduce into PHP 8.1, despite > our compatibility policy”, and turn it into a clear Yes/No question that > clearly requires a 2/3 majority. Since technically it might be an issue, > perhaps we can stick with the current wording, but still make it clear that > for 8.1 to be chosen, it’s have to obtain a 2/3 supermajority. > > I think those are fairly minor amendments that can be done without > restarting the vote, given where it’s at. > > Zeev
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey, Most of the internals who voted no, as far as I know, did so due to subjective reasons (i. e. don't want to allow declaring constructors/destructors as `void`). I don't think that should affect on what you believe is a change for better or for worse. As I mentioned before, it doesn't make much sense to allow `__clone` to be declared as `void` and make constructors/destructors an exception. As for the BC break, yes, only people who return something from a constructor/destructor are in trouble and will get a deprecation warning in PHP 8.0. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 3:47 PM Peter Bowyer wrote: > Hi, > > I have voted in favour, but enough people I respect have voted against to > make me reconsider. > > My understanding is the changes will only cause problems to people who > have returned something from __construct() or __destruct(). As people > shouldn't have done this, IMO it is a smaller BC issue than the BC break > that would have been caused if the proposed #[] attribute syntax had been > chosen. > > Peter > > On Thu, 2 Jul 2020 at 22:12, Benas IML wrote: > >> Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> >> Best regards, >> Benas Seliuginas >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
> > I think that Larry's and Rowan's replies on the original discussion thread >> really well explained as to why it makes sense to allow an explicit `void` >> return type, so I'll just quote them instead ;) >> >> Larry: >> > I see this in the same category as __toString(). >> > > I read those yes, but there are subtle yet critical differences to me: > > in PHP < 8, 1. the return-type of __toString is already enforced by the > engine (just not by the type-system, but the end result is the same) and 2. > it is already allowed to add the "string" return type to the method. > > for constructors/destructors, neither 1. nor 2. are true: they *do*not* > allow any return type and they don't check the return value. > > This means that the change on __toString is mostly transparent (only the > exact error message is different), while the proposed change is not. It > will have a cost for the community, and my opinion is that this cost is not > worth it. > Well, for `__clone` neither 1 nor 2 are true as well. But as of PHP 8.0 it will be allowed to declare an explicit `void` return type on `__clone`. Thus, this will have a higher cost for the community since this behavior will be quite inconsistent with constructors/destructors which do not allow to declare an explicit return type. > > Any constructor returning non-void right now is Doing It Wrong(tm) >> > > That's precisely what I read as "gratuitous strictness" (no offense to > anyone, I respect this opinion.) > Especially when this might become "enforced". > That is rather subjective. Adding an explicit `void` return type allows to clearly show developer's intention to not return values from a constructor/destructor. While some people might not see any value in this, I personally do (and many others too). Moreover, as mentioned before, adding an explicit `void` return type causes the check to already be done in PHP 8.0. Which otherwise implicitly will only be done in PHP 8.1/9.0. > > >> Since some internals told me that PHP doesn't follow semver strictly, it >> would make sense to enforce the check in PHP 8.1 already. >> > > I invite you to read https://wiki.php.net/rfc/releaseprocess where this > is detailed. > Here is the relevant excerpt: "x.y.z to x.y+1.z" => "Backward > compatibility must be kept". > > A dedicated vote in a specific RFC cannot overrule this policy AFAIK. > See Nikita's reply. But if more internals find this controversial, I can close the secondary vote, that's okay with me. > Thanks for your answer, > Nicolas > Best regards, Benas >
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Benjamin, Some internals told me that PHP doesn't follow semver strictly and it should be okay to enforce `void` rules in PHP 8.1 already. Naturally, I raised that issue on the mailing list but got no replies. So, I have put that question as a secondary vote instead. By the way, is there any particular reason you voted no? If there are any questions, let me know. Best regards, Benas Seliuginas On Fri, Jul 3, 2020, 12:04 PM Benjamin Eberlei wrote: > > > On Thu, Jul 2, 2020 at 11:12 PM Benas IML > wrote: > >> Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> >> Best regards, >> Benas Seliuginas >> > > Hi Benas, > > I wanted to raise what I believe is an issue with the secondary vote going > against PHP policy to introduce a BC break in 8.1, I would imagine policy > overrules voting decision here and it wouldn't matter what people voted > for, it will only be removed at the earliest in 9.0 > > greetings > Benjamin > > >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >>
Re: [PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey Nicolas, Hey internals, >> >> I have opened the voting for the RFC, let's hope everything is going >> to be smooth :). If you have any other questions, let me know! >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> > > Hi Benas, > > I voted "no" to the RFC because to me adding "void" to constructor and > destructor don't add any value: the semantics of these functions are > totally defined. Annotating the code with "void" is duplicate information. > I think that Larry's and Rowan's replies on the original discussion thread really well explained as to why it makes sense to allow an explicit `void` return type, so I'll just quote them instead ;) Larry: > I see this in the same category as __toString(). > Adding `: string` to that method provides exactly zero additional information. You know it's going to return a string. That's it's whole purpose. On the off chance someone is returning a non-string right now, they're very clearly Doing It Wrong(tm). However, the stringable RFC added the ability to put `: string` on the method in order to be clearer, more explicit, and to not annoy type fans who are like "Ah, I've typed every one of my methods... except this one, because I can't, rh!" > I see this as the same for constructors. Any constructor returning non-void right now is Doing It Wrong(tm), and you know that going in. But being able to make the obvious explicit still has its advantages, both for documentation and for consistency. Rowan: > As long as it's possible to return things from constructors, then it is > "obvious" that a given constructor is void only in the same way that it > is "obvious" that a method called "convertToArray" returns an array. I > would be surprised if any style guide would forbid writing "public > function convertToArray(): array", so would be equally surprised to see > one forbid writing "public function __construct(): void". In both cases, > the extra marker takes the reader from 99% certain to 100%. Another thing to consider is that the explicit `: void` declaration causes the check to be enforced in PHP 8.0. Meanwhile, the implicit check will only be done in PHP 8.1/9.0 (depending on the secondary vote). best this can do is open another code-style bikeshed war. About forbidding > the functions from returning anything, I don't understand why this would > improve the overall quality of anything. To me, this looks like gratuitous > strictness. > Quite honestly, every feature/change in PHP results in some kind of a code-style war. It is not possible to be "politically" neutral. Moreover, allowing `__clone` (as of "Ensure correct magic methods' signature" RFC) to have an explicit `void` return type but disallowing that for constructors/destructors doesn't make much sense. In fact, that is more likely going to create a code style war since not allowing ctors/dtors to have an explicit type would be inconsistent. `__construct` and `__clone` work in a similar fashion yet `__clone` can have an explicit `void` return type and `__construct` - does not. I also don't understand the secondary vote: enforcing "void rules" in 8.1 > is a not-allowed BC break. This can only target 9.0 to me, there can be no > discussion about it in a specific RFC. Or did I miss something? > Since some internals told me that PHP doesn't follow semver strictly, it would make sense to enforce the check in PHP 8.1 already. I raised that question in the original thread but didn't get any replies on that matter. Thus, I have put this as a secondary vote. This is just my opinion on the matter of course. Thanks for contributing to > PHP. > ...and a highly appreciated one, thanks! Nicolas > Best regards, Benas Seliuginas >
[PHP-DEV] [RFC] [VOTE] Make constructors and destructors return void
Hey internals, I have opened the voting for the RFC, let's hope everything is going to be smooth :). If you have any other questions, let me know! RFC: https://wiki.php.net/rfc/make_ctor_ret_void Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [DISCUSSION] Make constructors and destructors return void
Since 2 weeks have passed and there wasn't much discussion, I would like to remind that I'm opening the vote on Friday (July 3rd). Best regards, Benas Seliuginas On Wed, Jun 17, 2020, 2:10 AM Benas IML wrote: > Hey internals, > > This is a completely refined, follow-up RFC to my original RFC. Based on > the > feedback I have received, this PR implements full validation and implicitly > enforces `void` rules on constructors/destructors while also allowing to > declare an **optional** explicit `void` return type. Note, that there is a > small but justifiable BC break (as stated by the RFC). > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas >
[PHP-DEV] Typed constants
Hey internals,
Is there any particular reason as to why constants cannot be typed? For example:
```
class Test {
// this is illegal
public const int TEST = 1;
}
```
Having typed constants would be quite beneficial. First of all, we
would obviously be more consistent with properties and functions ;)
But also, we could ensure that the correct type is retained during
inheritance. For example:
```
class Test {
public const TEST = 0;
}
class Test2 extends Test {
// this is legal (even though the type is different)
public const TEST = 'abc';
}
```
...but with typed constants, this would be possible:
```
class Test {
// this is legal
public const int TEST = 0;
}
class Test2 extends Test {
// this is illegal since the type is not declared
public const TEST = 'abc';
}
class Test3 extends Test {
// this is illegal since the type is not an integer
public const string TEST = 'abc';
}
class Test4 extends Test {
// this is illegal since the value is not an integer
public const int TEST = 'abc';
}
class Test5 extends Test {
// this is legal
public const int TEST = 1;
}
```
Moreover, even the PHP manual (e. g.
https://www.php.net/manual/en/class.reflectionclass.php) and numerous
RFCs (e. g. https://wiki.php.net/rfc/attribute_amendments) specify the
type for constants. This may confuse newcomers since that is actually
not allowed in PHP.
I am prepared to do all of the hard work and implement this myself, if
other internals also find this proposal a good idea.
Best regards,
Benas Seliuginas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2
Hey,
On Tue, Jun 23, 2020, 11:34 AM Ilija Tovilo wrote:
> Hi Benas
>
> >> I'd like to announce the match expression v2 RFC:
> >> https://wiki.php.net/rfc/match_expression_v2
>
> > Then it's not a standalone expression but a block. In this case, you
> cannot add an optional semicolon at all.
> >
> > But this RFC v2 is not proposing to add a block, therefore you won't be
> allowed to use `match` construct as a standalone expression anyways.
>
> Using match as a standalone expression is definitely allowed, just
> like any other expression.
>
> // This is fine, the semicolon is required
> match ($foo) {
> $bar => baz(),
> };
>
Yup but it won't return you out of the function. For example, this wouldn't
work:
```
function test(int $value): bool {
match($value) {
0 => false,
1 => true
}
}
$test = test(1);
```
But it seems by standalone expressions, Bjorn meant your example. Sorry for
the confusion, I thought he was referring to blocks.
> Ilija
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2
On Tue, Jun 23, 2020, 11:23 AM Björn Larsson
wrote:
> Den 2020-06-22 kl. 18:05, skrev Benas IML:
>
> > On Mon, Jun 22, 2020, 6:35 PM Björn Larsson
> > wrote:
> >
> >> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:
> >>
> >>> Hi Björn
> >>>
> >>>>> I'd like to announce the match expression v2 RFC:
> >>>>> https://wiki.php.net/rfc/match_expression_v2
> >>>> Well one could argue that when working with legacy code containing
> >>>> switch statements where one gradually migrates to match, it might be
> >>>> easier to have the same separator, i.e. ":".
> >>> I think that's somewhat of a moot point. The syntax of match is quite
> >>> different (match instead of switch, no case, no break, colon instead
> >>> of case, comma instead of semicolon, trailing semicolon). Just making
> >>> one of those the same doesn't make a meaningful difference for ease of
> >>> migration.
> >> Agree on that! One thing though. Is semicolon mandatory or is it
> optional
> >> like in the first RFC? Feels a bit odd with a semicolon after a curly
> >> bracket.
> >>
> > It's mandatory since it's an expression, not a block. Another example of
> an
> > expression would be a closure:
> >
> > ```
> > $fn = function () {
> > ...
> > }; // a semicolon is mandatory here.
> > ```
>
> Absolutely so. I was thinking of the case mentioned in v1 RFC when it's
> used
> as a stand-alone expression.
> match ($y) {
> ...
> };
>
Then it's not a standalone expression but a block. In this case, you cannot
add an optional semicolon at all.
But this RFC v2 is not proposing to add a block, therefore you won't be
allowed to use `match` construct as a standalone expression anyways.
` Optional?
>
> r//Björn L
>
Re: [PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2
On Mon, Jun 22, 2020, 6:35 PM Björn Larsson
wrote:
> Hi Ilija,Den 2020-06-18 kl. 22:51, skrev Ilija Tovilo:
>
> > Hi Björn
> >
> >>> I'd like to announce the match expression v2 RFC:
> >>> https://wiki.php.net/rfc/match_expression_v2
> >> Well one could argue that when working with legacy code containing
> >> switch statements where one gradually migrates to match, it might be
> >> easier to have the same separator, i.e. ":".
> > I think that's somewhat of a moot point. The syntax of match is quite
> > different (match instead of switch, no case, no break, colon instead
> > of case, comma instead of semicolon, trailing semicolon). Just making
> > one of those the same doesn't make a meaningful difference for ease of
> > migration.
> Agree on that! One thing though. Is semicolon mandatory or is it optional
> like in the first RFC? Feels a bit odd with a semicolon after a curly
> bracket.
>
It's mandatory since it's an expression, not a block. Another example of an
expression would be a closure:
```
$fn = function () {
...
}; // a semicolon is mandatory here.
```
>> Is the proposed => separator inspired by Rust or Scala? Checked what
> >> other languages used and for switch it's ":" of course. So one might
> >> argue that to align with match statements in other languages "=>" is
> >> a good choice, but OTOH if ones sees match as an enhanced switch,
> >> having ":" as a separator is another alternative.
> > Since nobody else asked for it, just for you I compiled a list of
> > other languages :)
> >
> > https://gist.github.com/iluuu1994/11ac292cf7daca8162798d08db219cd5
> >
> > The conclusion: Most languages also use some form of arrow. It makes
> > sense to me to stay consistent with those languages.
> >
> > Ilija
>
> I think this is a very good motivation on why select => as a symbol and
> I'm glad it's listed in the RFC.
>
> r//Björn
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Named arguments
Hey Nikita, This is a bit late response but ah, who cares ;-) I suppose that for consistency with named params, we should also make `declare` compatible with this syntax. So for example, `declare(strict_types: 1);` would be the same as `declare(strict_types=1)`. This would also make much more sense to newcomers and beginners. Best regards, Benas On Tue, 5 May 2020 at 16:51, Nikita Popov wrote: > > Hi internals, > > I've recently started a thread on resurrecting the named arguments proposal > (https://externals.io/message/109549), as this has come up tangentially in > some recent discussions around attributes and around object ergonomics. > > I've now updated the old proposal on this topic, and moved it back under > discussion: https://wiki.php.net/rfc/named_params > > Relative to the last time I've proposed this around PHP 5.6 times, I think > we're technically in a much better spot now when it comes to the support > for internal functions, thanks to the stubs work. > > I think the recent acceptance of the attributes proposal also makes this a > good time to bring it up again, as phpdoc annotations have historically had > support for named arguments, and this will make migration to the > language-provided attributes smoother. > > Regards, > Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Andreas, > Another example would be the "public" access specifier, which can be omitted and the method will still be public. > > There is a major difference though: > > If you look at a method without "public", or a parameter without "mixed", there is a chance that the developer actually should have put something else here, e.g. "private" or "string", and was simply too lazy, was not aware of that possibility, or wrote the code with a prior PHP version in mind. > Having the explicit keyword documents an intentional choice to make the method public, to make the parameter mixed, etc. `: void` on constructor/destructor also helps to explicitly show the developer's intention to not return a value. > There are conventions or popular preference, and there are people or projects which want to do things their own way. And here's another reason why letting `: void` is a good idea. PHP should not enforce conventions but at most recommend them and allow the community to have the freedom of choice. > On the other hand, for a constructor the ": void" is just stating the obvious. > Even if you see a constructor without ": void", you still know that this is not meant to return anything. > Either because it is generally agreed to be bad (PHP7) or because it is deprecated (PHP8) or because it is illegal (PHP9) And why that matters? Everyone knows that the `__toString` method returns a `string` and everyone knows that the `__clone` method returns a `void`. In both those cases, adding an explicit return type is allowed. > But here there are actual technical arguments why someone might prefer one or the other solution I never said that I was referring to people having technical arguments? Anyways, this is not relevant to the RFC > And of course there is the time before agreements are reached in specific conventions, where people produce code which could be one way or the other. > I don't see a contradiction here. Again, I'm not sure what you're referring to. Best regards, Benas On Thu, Jun 18, 2020, 11:49 PM Andreas Hennings wrote: > > > On Thu, 18 Jun 2020 at 22:29, Benas IML wrote: > >> Hey Andreas, >> >> It seems that you actually haven't read my reply carefully enough. >> >> > But this distinction would only apply in PHP 8. And the only difference >> here >> is whether returning a value is just deprecated or fully illegal. >> > In PHP 9, constructors with ": void" would be the same as without ": >> void". >> So long term it will become a "meaningless choice". >> > >> > Or what am I missing? >> >> The "allowance" of `void` return type will help: >> - to be more explicit. >> - to enforce `void` rules on constructors/destructors (in PHP 8). >> - to be more consistent with other methods (which is what people like the >> most >> about allowing `void` on ctor/dtor based on r/php). >> - to be more consistent with the documentation. >> >> > Except consistency with existing constructors in other packages which >> choose >> to not add ": void" to constructors. >> > >> > Either it is enforced in a "code convention", or it is up to every >> single >> developer and team, and we get silly arguments between developers in code >> review whether or not this should be added. Or we get git noise because >> one >> developer adds those declarations, and another removes them. >> >> I find these comments of yours to make completely no sense since most of >> the >> additions to PHP will create some sort of silly arguments between >> developers. >> >> A best example would be the `mixed` type. Based on what you have said, >> this >> pseudo type will create inconsistencies because some libraries will have >> parameters explicitly declared as `mixed` while others - won't. It will >> also >> create arguments between developers on whether they should use it or not. >> >> Moving on, let's take the `void` type (implemented in PHP 7.1) as another >> great >> example! Laravel and Symfony (both depend on PHP 7.2) don't use it while >> other >> libraries - do. So, as I understand based on your comments, this is >> creating >> inconsistencies and arguments between developers. Some say `void` should >> be >> added, some say not. Some libraries declare it, some don't. >> > > Another example would be the "public" access specifier, which can be > omitted and the method will still be public. > > There is a major difference though: > > If you look at a method without "public", or a
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Andreas, It seems that you actually haven't read my reply carefully enough. > But this distinction would only apply in PHP 8. And the only difference here is whether returning a value is just deprecated or fully illegal. > In PHP 9, constructors with ": void" would be the same as without ": void". So long term it will become a "meaningless choice". > > Or what am I missing? The "allowance" of `void` return type will help: - to be more explicit. - to enforce `void` rules on constructors/destructors (in PHP 8). - to be more consistent with other methods (which is what people like the most about allowing `void` on ctor/dtor based on r/php). - to be more consistent with the documentation. > Except consistency with existing constructors in other packages which choose to not add ": void" to constructors. > > Either it is enforced in a "code convention", or it is up to every single developer and team, and we get silly arguments between developers in code review whether or not this should be added. Or we get git noise because one developer adds those declarations, and another removes them. I find these comments of yours to make completely no sense since most of the additions to PHP will create some sort of silly arguments between developers. A best example would be the `mixed` type. Based on what you have said, this pseudo type will create inconsistencies because some libraries will have parameters explicitly declared as `mixed` while others - won't. It will also create arguments between developers on whether they should use it or not. Moving on, let's take the `void` type (implemented in PHP 7.1) as another great example! Laravel and Symfony (both depend on PHP 7.2) don't use it while other libraries - do. So, as I understand based on your comments, this is creating inconsistencies and arguments between developers. Some say `void` should be added, some say not. Some libraries declare it, some don't. Moving on, attributes. If you go onto Reddit, you can see that the crowd is divided 50/50. Some believe that attributes are bad and say that they will use functions (for "adding" metadata) instead. Others prefer attributes and will use those. You can literally find people bashing each other for their preference. So that is creating heated arguments AND possibly future inconsistencies between different people/libraries. It's not possible to be "politically" neutral. Every single feature/code style is used by some group of people and isn't used by another. So next time please be more pragmatic. > So if you want to support PHP 7, you cannot add ": void". > If you only care about PHP 9, you don't need to add ": void" because it is pointless. > > Any convention would probably discourage it to be more universally usable. This is a completely contradicting statement. Just a few sentences ago you said that there will be silly arguments between people. But now as I understand, most conventions will probably discourage the explicit `: void` return type on constructors/destructors. Thus, since most people follow conventions, there will be little-to-no arguments. > Exactly my point. "Optional" means people will make arbitrary choices and argue about it, or look for a convention. Already addressed this. Best regards, Benas On Thu, Jun 18, 2020, 11:15 PM Andreas Hennings wrote: > > On Thu, 18 Jun 2020 at 18:33, Benas IML wrote: > >> Hey Andreas, >> >> That is incorrect. Adding an explicit `: void` does change behavior since >> only then the check (whether something is being returned) is enforced. This >> allows PHP 8 projects to take advantage of this enforcement while being >> respective to older codebases. >> >> Ok. I read more carefully now. > > But this distinction would only apply in PHP 8. And the only difference > here is whether returning a value is just deprecated or fully illegal. > In PHP 9, constructors with ": void" would be the same as without ": void". > So long term it will become a "meaningless choice". > > Or what am I missing? > > > >> And well, the explicit `: void` declaration also helps your code to be >> more consistent with other methods ;) >> > > Except consistency with existing constructors in other packages which > choose to not add ": void" to constructors. > > >> >> Without an explicit `: void` return type declaration, `void` rules are >> not enforced on constructors/destructors and will not be until PHP 9.0 >> (which will probably release in 5 years). >> >> Moreover, saying "it forces organisations, frameworks or the php-fig >> group to introduce yet another coding convention" is a complete >> exaggeration. In fact, e
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Bob, Your examples (regarding constructors/destructors) do make sense since you are using these methods for what they should be used: initialization and freeing resources. But, this is off-topic to the RFC. This RFC only proposes to enforce no-return rule on constructors/destructors. And based on my previous reply, top 2,000 Composer packages that have a BC break don't actually return anything (early returns and returns that don't change code behavior don't count). Your examples regarding `__toString`, `__invoke` and `__serialize` are also not relevant to this RFC. Although, I do understand that you were responding to email and I'm thankful for that :) Best regards, Benas On Thu, Jun 18, 2020, 7:43 PM Bob Weinand wrote: > Hey, > > Am 18.06.2020 um 17:18 schrieb Benas IML : > > Hey Bob, > > Magic methods are **never** supposed to be called directly (even more if > that method is a constructor or a destructor). If that's not the case, it's > just plain bad code. But by enforcing these rules, we make sure that less > of that (bad code) is written and as a result, we make PHP code less > bug-prone and easier to debug. That's also most likely the reason why > > > __construct() is invoked directly on parent calls, sometimes to > reinitialize an object or > after ReflectionClass::newInstanceWithoutConstructor. > > I invoke __destruct() directly when needing an early freeing of existing > resources. > > "ensure magic methods' signature" RFC opted in to validate `__clone` > method's signature and ensure that it has `void` return type. > > Just for the sake of making sure that you understand what I mean, here are > a couple of examples that show that no magic method is ever supposed to be > called directly: > ```php > // __toString > (string) $object; > > > I like using ->__toString() in favor of (string) casts when the variable > is guaranteed to be an object to highlight that and avoid magic-ness. > > // __invoke > $object(); > > > Same here, unless the object is a closure. > > // __serialize > serialize($object); > ``` > > > Can't argue much about that one, I never use serialize(). > > Moreover, by validating constructors/destructors and allowing an explicit > `void` return type declaration, we are becoming much more consistent > (something that PHP is striving for) with other magic methods (e. g. > `__clone`). > > > Yeah, __clone() is odd. No idea why. > > Also, saying that "sometimes you have valid information to pass from the > parent class" is quite an overstatement. After analyzing most of the 95 > Composer packages that had a potential BC break, I found out that either > they wanted to return early (that is still possible to do using `return;`) > or they added a `return something;` for no reason. Thus, no libraries > actually returned something useful and valid from a constructor (as they > shouldn't). > > Last but certainly not least, constructors have one and only one > responsibility - to initialize an object. Whether you read Wikipedia's or > PHP manual's definition, a constructor does just that. It initializes. So, > the PHP manual is perfectly correct and documents the correct return type > that a constructor should have. > > > It also is generally a bad idea to have side effects in constructors, but > _sometimes_ it is justified. Only because something mostly is a bad idea, > it is not always. > Also note that other languages completely forbid manual ctor calls. But > PHP doesn't (and for good reason, like after > using ReflectionClass::newInstanceWithoutConstructor). > > Bob > > Best regards, > Benas > > On Thu, Jun 18, 2020, 4:06 PM Bob Weinand wrote: > >> > Am 17.06.2020 um 01:10 schrieb Benas IML : >> > >> > Hey internals, >> > >> > This is a completely refined, follow-up RFC to my original RFC. Based >> on the >> > feedback I have received, this PR implements full validation and >> implicitly >> > enforces `void` rules on constructors/destructors while also allowing to >> > declare an **optional** explicit `void` return type. Note, that there >> is a >> > small but justifiable BC break (as stated by the RFC). >> > >> > RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> > >> > Best regards, >> > Benas Seliuginas >> >> Hey Benas, >> >> I do not see any particular benefit from that RFC. >> >> Regarding what the manual states - the manual is wrong there and thus >> should be fixed in the manual. This is not an argument for changing engine >> behaviour. >> >> Sometimes a constructor (esp. of a parent class) or destructor may be >> called manually. Sometimes you have valid information to pass from the >> parent class. >> With your RFC an arbitrary restriction is introduced necessitating an >> extra method instead. >> >> In general that RFC feels like "uh, __construct and __destruct are mostly >> void, so let's enforce it … because we can"? >> >> On these grounds and it being an additional (albeit mostly small) >> unnecessary BC break, I'm not in favor of that RFC. >> >> Bob > > >
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Alexandru, Your email was marked as spam for me, thus this is a late response, sorry about that! Nikita analyzed top 2,000 Composer packages and found that 95 of them will have a BC break. As a solution, to minimize the amount of BC breaks, I'm proposing to have a deprecation warning in PHP 8.0 and subsequently enforce `void` rules in later versions. Best regards, Benas On Wed, Jun 17, 2020, 3:44 AM Alexandru Pătrănescu wrote: > Hi Benas, > > This looks good to me. > > Can you do a research on top 1k-2k most used composer packages and verify > how small the BC break it is? > > Also, a suggestion on how to fix the BC issue if it exists could be > mentioned I guess. > > Thank you, > Aled > > On Wed, Jun 17, 2020, 02:11 Benas IML wrote: > >> Hey internals, >> >> This is a completely refined, follow-up RFC to my original RFC. Based on >> the >> feedback I have received, this PR implements full validation and >> implicitly >> enforces `void` rules on constructors/destructors while also allowing to >> declare an **optional** explicit `void` return type. Note, that there is a >> small but justifiable BC break (as stated by the RFC). >> >> RFC: https://wiki.php.net/rfc/make_ctor_ret_void >> >> Best regards, >> Benas Seliuginas >> >> -- >> PHP Internals - PHP Runtime Development Mailing List >> To unsubscribe, visit: https://www.php.net/unsub.php >> >>
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Andreas, That is incorrect. Adding an explicit `: void` does change behavior since only then the check (whether something is being returned) is enforced. This allows PHP 8 projects to take advantage of this enforcement while being respective to older codebases. And well, the explicit `: void` declaration also helps your code to be more consistent with other methods ;) Without an explicit `: void` return type declaration, `void` rules are not enforced on constructors/destructors and will not be until PHP 9.0 (which will probably release in 5 years). Moreover, saying "it forces organisations, frameworks or the php-fig group to introduce yet another coding convention" is a complete exaggeration. In fact, even now there are no PSR conventions that specify how and when to write parameter/return/property type hints. Also, it's important to understand that PHP libraries are really really slow at starting to **depend** on new PHP versions. It will probably take a few good years (if not more) until first few libraries start requiring PHP 8.0. As a matter of fact, even Symfony framework is still requiring PHP 7.2.5 and cannot take advantage of its newer features (e. g. typed properties). Last but not least, just to reiterate, the `: void` return type is optional and you don't need to specify it. Best regards, Benas On Thu, Jun 18, 2020, 7:02 PM Andreas Hennings wrote: > Hi > > The RFC introduces what I call a "meaningless choice", by making something > possible that is currently illegal, but which does not change behavior. > https://3v4l.org/daeEm > > It forces organisations, frameworks or the php-fig group to introduce yet > another coding convention to decide whether or not there should be a ": > void" declaration on constructors. > > I am ok with restricting the use of "return *;" inside a constructor. > But I don't like allowing the ": void" declaration. > > Greetings > > On Thu, 18 Jun 2020 at 17:18, Benas IML wrote: > >> Hey Bob, >> >> Magic methods are **never** supposed to be called directly (even more if >> that method is a constructor or a destructor). If that's not the case, >> it's >> just plain bad code. But by enforcing these rules, we make sure that less >> of that (bad code) is written and as a result, we make PHP code less >> bug-prone and easier to debug. That's also most likely the reason why >> "ensure magic methods' signature" RFC opted in to validate `__clone` >> method's signature and ensure that it has `void` return type. >> >> Just for the sake of making sure that you understand what I mean, here are >> a couple of examples that show that no magic method is ever supposed to be >> called directly: >> ```php >> // __toString >> (string) $object; >> >> // __invoke >> $object(); >> >> // __serialize >> serialize($object); >> ``` >> >> Moreover, by validating constructors/destructors and allowing an explicit >> `void` return type declaration, we are becoming much more consistent >> (something that PHP is striving for) with other magic methods (e. g. >> `__clone`). >> >> Also, saying that "sometimes you have valid information to pass from the >> parent class" is quite an overstatement. After analyzing most of the 95 >> Composer packages that had a potential BC break, I found out that either >> they wanted to return early (that is still possible to do using `return;`) >> or they added a `return something;` for no reason. Thus, no libraries >> actually returned something useful and valid from a constructor (as they >> shouldn't). >> >> Last but certainly not least, constructors have one and only one >> responsibility - to initialize an object. Whether you read Wikipedia's or >> PHP manual's definition, a constructor does just that. It initializes. So, >> the PHP manual is perfectly correct and documents the correct return type >> that a constructor should have. >> >> Best regards, >> Benas >> >> On Thu, Jun 18, 2020, 4:06 PM Bob Weinand wrote: >> >> > > Am 17.06.2020 um 01:10 schrieb Benas IML : >> > > >> > > Hey internals, >> > > >> > > This is a completely refined, follow-up RFC to my original RFC. Based >> on >> > the >> > > feedback I have received, this PR implements full validation and >> > implicitly >> > > enforces `void` rules on constructors/destructors while also allowing >> to >> > > declare an **optional** explicit `void` return type. Note, that there >> is >> > a >> > > small but justifiable BC break (as s
Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey Bob, Magic methods are **never** supposed to be called directly (even more if that method is a constructor or a destructor). If that's not the case, it's just plain bad code. But by enforcing these rules, we make sure that less of that (bad code) is written and as a result, we make PHP code less bug-prone and easier to debug. That's also most likely the reason why "ensure magic methods' signature" RFC opted in to validate `__clone` method's signature and ensure that it has `void` return type. Just for the sake of making sure that you understand what I mean, here are a couple of examples that show that no magic method is ever supposed to be called directly: ```php // __toString (string) $object; // __invoke $object(); // __serialize serialize($object); ``` Moreover, by validating constructors/destructors and allowing an explicit `void` return type declaration, we are becoming much more consistent (something that PHP is striving for) with other magic methods (e. g. `__clone`). Also, saying that "sometimes you have valid information to pass from the parent class" is quite an overstatement. After analyzing most of the 95 Composer packages that had a potential BC break, I found out that either they wanted to return early (that is still possible to do using `return;`) or they added a `return something;` for no reason. Thus, no libraries actually returned something useful and valid from a constructor (as they shouldn't). Last but certainly not least, constructors have one and only one responsibility - to initialize an object. Whether you read Wikipedia's or PHP manual's definition, a constructor does just that. It initializes. So, the PHP manual is perfectly correct and documents the correct return type that a constructor should have. Best regards, Benas On Thu, Jun 18, 2020, 4:06 PM Bob Weinand wrote: > > Am 17.06.2020 um 01:10 schrieb Benas IML : > > > > Hey internals, > > > > This is a completely refined, follow-up RFC to my original RFC. Based on > the > > feedback I have received, this PR implements full validation and > implicitly > > enforces `void` rules on constructors/destructors while also allowing to > > declare an **optional** explicit `void` return type. Note, that there is > a > > small but justifiable BC break (as stated by the RFC). > > > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > > > Best regards, > > Benas Seliuginas > > Hey Benas, > > I do not see any particular benefit from that RFC. > > Regarding what the manual states - the manual is wrong there and thus > should be fixed in the manual. This is not an argument for changing engine > behaviour. > > Sometimes a constructor (esp. of a parent class) or destructor may be > called manually. Sometimes you have valid information to pass from the > parent class. > With your RFC an arbitrary restriction is introduced necessitating an > extra method instead. > > In general that RFC feels like "uh, __construct and __destruct are mostly > void, so let's enforce it … because we can"? > > On these grounds and it being an additional (albeit mostly small) > unnecessary BC break, I'm not in favor of that RFC. > > Bob
[PHP-DEV] Re: [RFC] [DISCUSSION] Make constructors and destructors return void
Hey internals, 1. Since there is confusion around multiple RFCs, I would like to emphasize that this RFC (Make constructors and destructors return void) superseded the original RFC (Allow void return type on constructors/destructors). Thus, the latter RFC is now abandoned. Link to the new RFC: https://wiki.php.net/rfc/make_ctor_ret_void Link to the old RFC: https://wiki.php.net/rfc/constructor_return_type I would also like to inform you that the new RFC is now complete. As such, I have put the RFC into "Under Discussion" status. 2. Since this RFC is proposing a rather small BC break (given that there will be a deprecation warning in PHP 8.0), should we start enforcing `void` rules on constructors and destructors in PHP 8.1 or PHP 9.0? Best regards, Benas On Wed, Jun 17, 2020, 2:10 AM Benas IML wrote: > Hey internals, > > This is a completely refined, follow-up RFC to my original RFC. Based on > the > feedback I have received, this PR implements full validation and implicitly > enforces `void` rules on constructors/destructors while also allowing to > declare an **optional** explicit `void` return type. Note, that there is a > small but justifiable BC break (as stated by the RFC). > > RFC: https://wiki.php.net/rfc/make_ctor_ret_void > > Best regards, > Benas Seliuginas >
[PHP-DEV] Re: [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Just a heads up :) Both PR and the RFC were updated to reflect the changes and to minimize the amount of BC breaks. TL;DR the RFC proposes to deprecate returning non-void values from constructors/destructors in PHP 8.0 and always enforce void rules on constructors/destructors in PHP 9.0. Additionally, to allow declaring an explicit `: void` return type on constructors/destructors. Best regards, Benas On Tue, 16 Jun 2020 at 03:34, Benas IML wrote: > > Hey internals, > > I am proposing to allow void return type for constructors/destructors. Note, > that this is an **optional** and cosmetic-only addition! All of the reasoning > is in the RFC. > > RFC: https://wiki.php.net/rfc/constructor_return_type > > Best regards, > Benas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Hey Christian,
Wrong wording, sorry! :)
> But I definitely wouldn't want a deprecation warning for constructors without
> explicit ': void' as I see no reason to force people to use it.
This RFC proposes 2 things:
1) If a non-void value is returned from a constructor/destructor, a
deprecation warning is thrown. Meanwhile, in PHP 9.0 a fatal error is
thrown instead.
2) It will be allowed to declare constructors/destructors explicitly
as `: void` (previously this was illegal).
Best regards,
Benas
On Wed, 17 Jun 2020 at 16:36, Christian Schneider wrote:
>
> Am 17.06.2020 um 13:59 schrieb Benas IML :
> > We should allow newer codebases to enforce `void` rules on
> > constructors/destructors by allowing to explicitly declare return type as
> > `void`.
>
> I don't see a big benefit in this explicit return type void as newer
> codebases hopefully will try to get rid of deprecation warnings and thus
> fixing it but if you think this is helpful then I'll shut up :-)
>
> > Meanwhile, we should throw a deprecation warning, if the
> > constructor/destructor is
> > returning a non-void value and doesn't have an explicit `: void`
> > declaration.
>
> I'm not sure I understand the second part "and doesn't have an explicit `:
> void` declaration".
> If there is a ' : void' declaration then returning any value will be an error.
> As far as I can see this is already the case:
> php -r 'class A { function __construct() : void { return 42; } }'
> with PHP 7.4 gives
> PHP Fatal error: A void function must not return a value in Command
> line code on line 1
>
> But I definitely wouldn't want a deprecation warning for constructors without
> explicit ': void' as I see no reason to force people to use it.
>
> > Then, presumably in PHP 9, in addition to explicit `: void`, also enforce
> > `void` rules implicitly
> > altogether.
>
> Yes, that's how I would do it.
>
> - Chris
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Thanks everybody for the replies. > However, I am also fine if the void return value is only enforced when the > void return > type is declared. Additionally, we could emit a deprecation notice/warning > when > there is no return type declaration, but a value is returned. I think this > would be > a nice way to immediately give people the possibility to disallow a return > value, > while being respectful for older code bases. Completely agreed. I'll update the RFC to reflect this as well. We should allow newer codebases to enforce `void` rules on constructors/destructors by allowing to explicitly declare return type as `void`. Meanwhile, we should throw a deprecation warning, if the constructor/destructor is returning a non-void value and doesn't have an explicit `: void` declaration. Then, presumably in PHP 9, in addition to explicit `: void`, also enforce `void` rules implicitly altogether. Best regards, Benas On Wed, 17 Jun 2020 at 11:31, Máté Kocsis wrote: >> >> This PR should also address all of Máté's concerns since it makes >> constructors and destructors always return `void` (even when no explicit >> `void` return type is specified). > > > To be clear, my main concern was that declaring a void return type shouldn't > be > allowed, unless it's actually enforced. Now, it's all fine because you stated > your > intentions :) > > However, I am also fine if the void return value is only enforced when the > void return > type is declared. Additionally, we could emit a deprecation notice/warning > when > there is no return type declaration, but a value is returned. I think this > would be > a nice way to immediately give people the possibility to disallow a return > value, > while being respectful for older code bases. > > Regards, > Máté > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void
Hey internals, This is a completely refined, follow-up RFC to my original RFC. Based on the feedback I have received, this PR implements full validation and implicitly enforces `void` rules on constructors/destructors while also allowing to declare an **optional** explicit `void` return type. Note, that there is a small but justifiable BC break (as stated by the RFC). RFC: https://wiki.php.net/rfc/make_ctor_ret_void Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] Re: [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Hey internals, I put the original RFC on hold and created a new PR [0] for implicitly enforcing `void` rules on both constructors and destructors. Note, that this results in a BC break since it is no longer legal to return non-void value from constructors/destructors. In other words, it is now illegal to return something from ctor. As a side bonus, it is also allowed to explicitly declare both `__construct()` and `__destruct()` as `void` (but this is by no means mandatory, it's optional). I'm not sure whether this needs a proper RFC since this is more of a patch (fix: #79679) than a new feature, so let me know! This PR should also address all of Máté's concerns since it makes constructors and destructors always return `void` (even when no explicit `void` return type is specified). Best regards, Benas Seliuginas On Tue, Jun 16, 2020, 3:34 AM Benas IML wrote: > Hey internals, > > I am proposing to allow void return type for constructors/destructors. > Note, > that this is an **optional** and cosmetic-only addition! All of the > reasoning > is in the RFC. > > RFC: https://wiki.php.net/rfc/constructor_return_type > > Best regards, > Benas >
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Nope, that isn't changing.
I simply wanted to point out that this RFC is proposing to allow to declare
constructor return type as `: void`, but not as `: mixed`.
The entire RFC is just a matter of cosmetic addition allowing to add `:
void` to constructors/destructors (for those that want to).
It seems that I will have to rewrite the BC section to be more clear on
that.
Best regards,
Benas
On Tue, Jun 16, 2020, 5:36 PM Christoph M. Becker wrote:
> On 16.06.2020 at 16:19, Benas IML wrote:
>
> > I meant something like this:
> > ```
> > > class Test {
> > public function __construct() {}
> > }
> >
> > class Test2 extends Test {
> > /* this is legal */
> > public function __construct(): void {}
> > }
> >
> > class Test3 extends Test {
> > /*
> > * this is illegal, even though no
> > * return type means mixed|void
> > */
> > public function __construct(): mixed {}
> > }
> >
> > class Test4 extends Test2 {
> > /*
> > * this is legal, even though we are
> > * widening void type to mixed|void
> > * but LSP checks don't apply to
> > * constructors and destructors
> > */
> > public function __construct() {}
> > }
> > ```
>
> Currently, constructors are exempt from LSP checks[1]; are you planning
> to change that?
>
> [1] <https://3v4l.org/PeDCY>
>
> --
> Christoph M. Becker
>
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Exactly :)
Personally, I have numerous times caught myself declaring constructors `:
void` too. I would love to have everything consistent and all methods to
have a return type.
Although, I do understand that not everybody agrees with me and that's why
this RFC isn't planning to ever force people to use `void` return type.
As I have said before: some might use it, some might not, but both cases
are valid and allowed :)
Best regards,
Benas
On Tue, Jun 16, 2020, 5:11 PM Jesse Rushlow wrote:
> From a PHP developer's POV - when writing a class or refactoring one. I
> have to catch myself all the time trying to declare ": void" on the
> constructor. It's mostly a habit from doing so with the other methods in
> the class. I lean in favor of being able to declare a void return type on a
> constructor, but only for the aforementioned reason. I have never ran into
> a use case where I've questioned what the return type is for a constructor.
> Although I could see newcomers to PHP / Development in general ponder that
> thought.
>
> Thanks,
> Jesse Rushlow
>
> On Tue, Jun 16, 2020 at 8:59 AM Dan Ackroyd
> wrote:
>
>> G.P.B. wrote:
>> > Seems like a no brainer and a good addition. :)
>>
>> For situations where stuff is simple, 'no brainers' are okay.
>> For situations where everything is horribly convoluted, 'no brainers'
>> are often bad.
>>
>> Benas IML wrote:
>> > even though no return type means mixed|void
>>
>> Not quite.
>>
>> No return type is _treated as_ 'mixed|void' in some circumstances
>> particularly signature checks during inheritance. That's not quite the
>> same as 'meaning' the same.
>>
>> > What I meant, was that since no return type means `mixed|void`,
>> > you can't do the following:
>>
>> I'm actually not sure exactly what you're trying to say there, but I
>> think pasting the text I reference whenever trying to think about LSP
>> might be useful...
>>
>> "PHP allows contravariance (aka type widening) for parameter types to
>> obey the LSP principle. A subclass may use a 'wider' aka less specific
>> type in place of the inherited type for a parameter."
>>
>> "PHP allows covariance (aka type narrowing) for return types to obey
>> the LSP principle. A subclass may use a 'narrower' aka more specific
>> type in place of the inherited type for a function return."
>>
>> > I am proposing to allow void return type for constructors/destructors.
>>
>> Constructors in PHP have multiple issues that are 'surprising'. I'm
>> not sure that fixing only a small part of how they are surprising,
>> improves PHP drastically.
>>
>> Also...I really wish we already had null as a usable type, as most of
>> the uses of void are slightly inaccurate.
>>
>> The meaning of void and null are:
>>
>> void - this function doesn't return a value
>> null - this function returns a value that has no information in it.
>>
>> Presumably you want to be able to specify void as the return type to
>> make it be easier to detect errors in code like the example you
>> provided.
>>
>> It seems that making a rule for whichever static analyzer you're
>> using, that errors on any assigning of a value from a __construct
>> call, would achieve that, without touching a part of PHP that is full
>> of edge cases.
>>
>> To be clear, I'm not sure if I am in favour or against the RFC. The
>> real problem is that constructors just don't fit into how we think
>> about normal functions is PHP, because of the magic that goes on
>> around them and so both void and null as return types would be a
>> little bit incorrect.
>>
>> cheers
>> Dan
>> Ack
>>
>>
>>
>> Some example functions using those two return types.
>>
>> function this_is_void_return(): void {
>>exit(0);
>> }
>>
>> function this_is_also_void_return(): void {
>>throw new Exception("no usuable return value");
>> }
>>
>> function this_is_also_also_void_return(): void {
>>while (1) {
>>echo "Hello world\n";
>>}
>> }
>>
>> function this_is_null_return(): null {
>> // deliberately empty.
>> }
>>
>> // This code is fine.
>> var_dump(this_is_null_return());
>>
>> // This code is never going to execute the var_dump, which
>> // might indicate an error.
>> var_dump(this_is_void_return());
>> var_dump(this_is_also_void_return());
>> var_dump(this_is_also_also_void_return());
>>
>> --
>> PHP Internals - PHP Runtime Development Mailing List
>> To unsubscribe, visit: http://www.php.net/unsub.php
>>
>>
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Hey Dan,
Thanks for your reply.
> No return type is _treated as_ 'mixed|void' in some circumstances
Could you elaborate? No return type DOES mean `mixed|void`, could you give
any pointers as to where that is different?
> I'm actually not sure exactly what you're trying to say there
I meant something like this:
```
wrote:
> G.P.B. wrote:
> > Seems like a no brainer and a good addition. :)
>
> For situations where stuff is simple, 'no brainers' are okay.
> For situations where everything is horribly convoluted, 'no brainers'
> are often bad.
>
> Benas IML wrote:
> > even though no return type means mixed|void
>
> Not quite.
>
> No return type is _treated as_ 'mixed|void' in some circumstances
> particularly signature checks during inheritance. That's not quite the
> same as 'meaning' the same.
>
> > What I meant, was that since no return type means `mixed|void`,
> > you can't do the following:
>
> I'm actually not sure exactly what you're trying to say there, but I
> think pasting the text I reference whenever trying to think about LSP
> might be useful...
>
> "PHP allows contravariance (aka type widening) for parameter types to
> obey the LSP principle. A subclass may use a 'wider' aka less specific
> type in place of the inherited type for a parameter."
>
> "PHP allows covariance (aka type narrowing) for return types to obey
> the LSP principle. A subclass may use a 'narrower' aka more specific
> type in place of the inherited type for a function return."
>
> > I am proposing to allow void return type for constructors/destructors.
>
> Constructors in PHP have multiple issues that are 'surprising'. I'm
> not sure that fixing only a small part of how they are surprising,
> improves PHP drastically.
>
> Also...I really wish we already had null as a usable type, as most of
> the uses of void are slightly inaccurate.
>
> The meaning of void and null are:
>
> void - this function doesn't return a value
> null - this function returns a value that has no information in it.
>
> Presumably you want to be able to specify void as the return type to
> make it be easier to detect errors in code like the example you
> provided.
>
> It seems that making a rule for whichever static analyzer you're
> using, that errors on any assigning of a value from a __construct
> call, would achieve that, without touching a part of PHP that is full
> of edge cases.
>
> To be clear, I'm not sure if I am in favour or against the RFC. The
> real problem is that constructors just don't fit into how we think
> about normal functions is PHP, because of the magic that goes on
> around them and so both void and null as return types would be a
> little bit incorrect.
>
> cheers
> Dan
> Ack
>
>
>
> Some example functions using those two return types.
>
> function this_is_void_return(): void {
>exit(0);
> }
>
> function this_is_also_void_return(): void {
>throw new Exception("no usuable return value");
> }
>
> function this_is_also_also_void_return(): void {
>while (1) {
>echo "Hello world\n";
>}
> }
>
> function this_is_null_return(): null {
> // deliberately empty.
> }
>
> // This code is fine.
> var_dump(this_is_null_return());
>
> // This code is never going to execute the var_dump, which
> // might indicate an error.
> var_dump(this_is_void_return());
> var_dump(this_is_also_void_return());
> var_dump(this_is_also_also_void_return());
>
Re: [PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Hey Máté,
On Tue, Jun 16, 2020, 11:31 AM Máté Kocsis wrote:
> Hi Benas,
> Overall, I'm very much in favour of disallowing returning a value from
constructors.
> However, I think the RFC should deal with the return value and the
signature validation
> in the same time, so that we can vote about both, since introducing the
latter check
> is not just a bug fix, it's a substantial change IMO.
>
> What I would like to avoid for sure is that the void return type is not
actually enforced.
> (Offtopic: It seems that the magic method signature RFC exactly does
this, and I'm not
> happy about it. I'd welcome an amendment RFC to fix the new
inconsistencies).
Since there was a second PR already in the works on dealing with the return
value, I wasn't sure whether it was a good idea to implement that. But, I'm
happy to join forces and will contact the PR's author :)
> Furthermore, I personally also like the concept of an explicit return
type declaration for
>constructors, but Nikita's earlier argument against (that most languages
forbid the explicit
> return type) makes me think. Anyhow, this counterargument might be worth
to add to the RFC.
I should have emphasized more on this but PHP constructors aren't like any
other language constructors, since they are normal methods that can be
called by simply doing `$object->__construct();`.
I'm not sure if any other language allows you to do something similar.
> And regarding the last section of the RFC (Backward Incompatible
Changes), I'm not exactly
> sure what you mean there, but since constructors are exempt to LSP
validation, I think
> it's ok if a child class overrides the parent constructor with a widened
return type.
>
> Regards,
> Máté
What I meant, was that since no return type means `mixed|void`, you can't
do the following:
```
public function __construct(): mixed {}
```
But yes, it is allowed to widen the type from `void` to no return type.
Best regards,
Benas
[PHP-DEV] [RFC] [DISCUSSION] Allow void return type for constructors/destructors
Hey internals, I am proposing to allow void return type for constructors/destructors. Note, that this is an **optional** and cosmetic-only addition! All of the reasoning is in the RFC. RFC: https://wiki.php.net/rfc/constructor_return_type Best regards, Benas
Re: [PHP-DEV] [RFC] Shorter attribute syntax
+1
On Tue, Jun 9, 2020, 2:56 PM Benjamin Eberlei wrote:
> On Thu, Jun 4, 2020 at 1:55 AM Theodore Brown
> wrote:
>
> > Hi internals,
> >
> > I discussed the syntax for attributes further with Benjamin, Martin,
> > and several other internals developers off-list, and with their
> > feedback completed an RFC proposing to use the shorter `@@` syntax
> > instead of `<<>>` for attributes in PHP 8.
> >
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> >
> > The goal is not to bikeshed over subjective syntax preferences,
> > but to address several concrete shortcomings related to verbosity,
> > nested attributes, confusion with generics and other tokens, and
> > dissimilarity to other common languages.
> >
>
> Larry's suggestion about #[Attr] makes an important argument about allowing
> to declare attributes in code in PHP 7 in a forward compatible way that has
> not been brought up before.
>
> /** @ORM\Entity */
> #[ORM\Entity]
> class User {}
>
> This code would work on PHP 7 and 8.
>
> The #[] syntax would have about equally low breaking potential as @@. It
> would be the same syntax as Rusts, and close to C++/C# syntax.
>
> As such, instead of going through each alternative syntax one by one, with
> with each having a 2/3 requirement to overthrow the old one,
> I would be open to restart the secondary vote on Attributes syntax with
> <<>> (status quo), @@ and #[] using the same ranked voting algorithm that
> was used for the PHP 8 RM vote.
>
> @Sara @Gabriel I suppose this is something you two should be ok with (and
> Theodore of course).
>
> I would take on the work to write about the third syntax alternative then.
> The VoteRFC could just link to the three individual RFCs where each
> discusses their syntax.
>
>
> >
> > Best regards,
> > Theodore
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
Re: [PHP-DEV] [VOTE] Attribute Amendments
Hey,
I'm not sure what you're referring to as "generic variable system" but
given that you mentioned "type", I assume you mean typed variables? If so,
PHP is never going to have typed variables due to performance implications.
As for the `/**` and `*/`, I believe Marco was talking about Doctrine
Annotations. For example, instead of writing this:
```
/**
* @Route("/users", methods={"GET"})
* @OtherAnnotation
*/
```
...we would write:
```
<<
Route("/users", ["GET"]),
OtherAnnotation
>>
```
Best regards,
Benas
On Mon, Jun 8, 2020, 7:47 PM Lester Caine wrote:
> On 08/06/2020 16:30, Benjamin Eberlei wrote:
> >
> >
> > On Mon, Jun 8, 2020 at 11:11 AM Lester Caine > > wrote:
> >
> > On 08/06/2020 09:44, Marco Pivetta wrote:
> > > I was mostly conflicted around the "allow grouped attributes"
> > bit, but
> > > James Titcumb (who currently cannot write to this list due to
> bounced
> > > emails) convinced me that it is a good replacement for `/**` and
> > `*/`:
> >
> > If twenty years of documentation provided by docblocks is to be
> > replaced
> > there has to be a compelling reason to do so and while this latest
> > drive
> > for yet another documentation method seems to be now a fate acompli
> > there WAS no reason to replace that perfectly acceptable
> documentation!
> >
> >
> > Attributes are not documentation (they could theoretically be used for
> > it, but its not the intented use-case).
> >
> > Attributes are supposed to be used with Runtime Reflection to have an
> > effect on the program.
> >
> > Their existence does not supersede docblocks, only the use of docblocks
> > for meta-programming (essentially doing what Attributes allows with
> > docblocks).
>
> So the statement that "it is a good replacement for `/**` and `*/`" is
> not correct ... it may be that others do not understand the difference?
> Personally none of this is addressing the fundamental problem of
> providing a generic variable system that can manage range as well as
> 'type' ... something the docblock have been providing for a long time
> and moving part of that to some new element is only making things worse :(
>
> --
> Lester Caine - G8HFL
> -
> Contact - https://lsces.uk/wiki/Contact
> L.S.Caine Electronic Services - https://lsces.uk
> Model Engineers Digital Workshop - https://medw.uk
> Rainbow Digital Media - https://rainbowdigitalmedia.uk
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] Re: [RFC] Amendments to Attributes
Thank you for the update! Given that there is still an open issue, is the RFC proposing flags or a separate `<>` attribute? Best regards, Benas On Thu, Jun 4, 2020, 12:29 PM Benjamin Eberlei wrote: > I have changed back the rename from namespacing to Attributes\Attribute to > using just Attribute after a few discussions off list. The reasoning is > that it becomes more clear that a majority of core contributors strongly > prefers using the global namespace as the PHP namespace and opening up this > point again makes no sense. So the state of the RFC is again what it was > when I originally posted it with renaming PhpAttribute to Attribute. > > Unless there is some new significant feedback I am going to open up this > RFC for voting on Monday next week. > > On Wed, May 20, 2020 at 7:07 PM Benjamin Eberlei > wrote: > > > Hi everyone, > > > > the Attributes RFC was rather large already, so a few things were left > > open or discussions during the vote have made us rethink a things. > > > > https://wiki.php.net/rfc/attribute_amendments > > > > These points are handled by the Amendments RFC to Attributes: > > > > 1. Proposing to add a grouped syntax < > > 2. Rename PhpAttribute to Attribute in global namespace (independent of > > the namespace RFC) > > 3. Add validation of attribute class targets, which internal attributes > > can do, but userland can't > > 4. Specification if an attribute is repeatable or not on the same > > declaration and fail otherwise. > > > > Each of them is a rather small issue, so I hope its ok to aggregate all > > four of them in a single RFC. Please let me know if it's not. > > > > greetings > > Benjamin > > >
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hey! That's why I am against this RFC or any other "change style to what I prefer". PHP's current attribute syntax is consistent with other languages and poses no BC breaks whatsoever. Best regards, Benas On Thu, Jun 4, 2020, 1:37 PM Ilija Tovilo wrote: > > > Does the PHP parser prevent us from adopting #[attr]? I presume C#'s > [attr] > > > syntax and C++'s [[attr]] are impossible due to PHP's short array > syntax. > > > > yes, that would create ambiguity in the parser since `#` (just like `//`) > > is for comments. > > I've mentioned this off-list before. If we consider @@ with a BC break > we could also consider #[] by making #[ a symbol. > This is also a breaking change but a probably similarly small one. It > would break code like this: > > # Comments still work > #[ <-- But they can't start with #[ > > To me both of those look acceptable but #[ looks nicer (but that's > just my personal preference). > > Ilija > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hello, yes, that would create ambiguity in the parser since `#` (just like `//`) is for comments. Best regards, Benas On Thu, Jun 4, 2020, 11:03 AM Peter Bowyer wrote: > Hi Theodore, > > On Thu, 4 Jun 2020 at 00:55, Theodore Brown > wrote: > > > https://wiki.php.net/rfc/shorter_attribute_syntax > > > Thanks for creating this RFC and for including "Comparison to other > languages" in it. A provisional +1 from me. > > Does the PHP parser prevent us from adopting #[attr]? I presume C#'s [attr] > syntax and C++'s [[attr]] are impossible due to PHP's short array syntax. > > Peter >
Re: [PHP-DEV] [RFC] Shorter attribute syntax
Hello, thank you for the RFC but I hope it doesn't pass. Here's my constructive feedback as to why. Verbosity? Are we really debating whether adding 2 extra characters is more "verbose"? Well, with 3 or more grouped attributes, we are less verbose by 1 character. I don't find "verbosity" to be an argument as to why we should use the `@@` syntax. Moreover, we become inconsistent with basically every other programming language. Even `<<...>>` syntax is more consistent since our sister language Hack has it. I don't think it's a good idea to reinvent the wheel. And well, a BC break, even as small as it, is a BC break. Best regards, Benas On Thu, Jun 4, 2020, 2:55 AM Theodore Brown wrote: > Hi internals, > > I discussed the syntax for attributes further with Benjamin, Martin, > and several other internals developers off-list, and with their > feedback completed an RFC proposing to use the shorter `@@` syntax > instead of `<<>>` for attributes in PHP 8. > > https://wiki.php.net/rfc/shorter_attribute_syntax > > The goal is not to bikeshed over subjective syntax preferences, > but to address several concrete shortcomings related to verbosity, > nested attributes, confusion with generics and other tokens, and > dissimilarity to other common languages. > > Best regards, > Theodore > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] Avoid ending up in Spam
Hey, Here's a quote from Ben Ramsey that basically sums up the problem: > This appears to be happening due to DMARC rules on the domains of the senders. > I had the same thing happen to my emails, so I had to relax my DMARC rules. If > your rules are set too strict, servers see the From address coming from a > server not authorized by the domain, so it gets quarantined. Best regards, Benas On Sat, May 30, 2020, 1:03 AM Jakob Givoni wrote: > Hi internals, > > Sorry for the off-topic, but I need to ask you on this list, how do you > guys avoid having your emails ultimately ending up in the spam folders of > the mailing list recipients? > > I had troubles in the past so now I'm using this new gmail account as > someone suggested, hoping you will at least see this message. > Is it true that there's no other solution than using gmail? > > Best regards, > Jakob Givoni >
Re: [PHP-DEV] [RFC] Amendments to Attributes
It seems that the RFC was updated to use the `Attributes` namespace. I think this is a bad idea since we're reserving a generic namespace that we haven't even "soft" reserved. Also, the loss of fallback to global namespace is a turning point for me. Generally, I think we should instead do something like Rowan said: use namespaced classes only for implementations (e.g. `\Attribute` but `\PHP\Deprecated`). Best regards, Benas On Wed, May 20, 2020, 8:08 PM Benjamin Eberlei wrote: > Hi everyone, > > the Attributes RFC was rather large already, so a few things were left open > or discussions during the vote have made us rethink a things. > > https://wiki.php.net/rfc/attribute_amendments > > These points are handled by the Amendments RFC to Attributes: > > 1. Proposing to add a grouped syntax < > 2. Rename PhpAttribute to Attribute in global namespace (independent of the > namespace RFC) > 3. Add validation of attribute class targets, which internal attributes can > do, but userland can't > 4. Specification if an attribute is repeatable or not on the same > declaration and fail otherwise. > > Each of them is a rather small issue, so I hope its ok to aggregate all > four of them in a single RFC. Please let me know if it's not. > > greetings > Benjamin >
Re: [PHP-DEV] SPL development interest
Hey, yes, there are no traits at the moment. Also, in PHP 8 there was `WeakMap` class added to the core as well. Best regards, Benas Seliuginas P.S: your email is marked as spam for me and probably for everyone else too, so most of the internals probably missed your emails. Try using a gmail-based email account instead since those tend to passthru spam protection better.
Re: [PHP-DEV] [RFC] Amendments to Attributes
That's a brilliant idea, completely agreed, Rowan! On the other note, don't want to nitpick here but I believe that it would be better to name the repeatable attribute simply as `<>`. It would match other languages (such as Java) and the naming wouldn't be that verbose. Also IMO, I think for consistency we should either use only parameters e. g. `<>` or separate attributes for both target validation and repeatability e. g. `<>` and `<>`. Best regards, Benas Seliuginas
Re: [PHP-DEV] [RFC] Amendments to Attributes
Agreed. I don't think we should pollute any other than the `PHP\` namespace. If that RFC doesn't pass though, we should keep the `Attribute` class in the global namespace. Global namespace is already reserved for PHP and so, BC breaks aren't that severe whereas `Attributes\` namespace isn't reserved therefore BC breaks would be "unexpected". Best regards, Benas Seliuginas
Re: [PHP-DEV] [RFC] Amendments to Attributes
Hello, Would it possible to make a separate RFC for renaming `PhpAttribute` to `Attribute` and `PhpCompilerAttribute` to `CompilerAttribute`? Since it would a huge BC break changing this in PHP 8.1. Best regards, Benas Seliuginas
Re: [PHP-DEV] [RFC] Amendments to Attributes
Hey, I personally think that `UserlandAttribute` is too verbose and a quite useless change since just using `Attribute` will make little to no BC compatibility breaks (we know that thanks to Rowan, please check out Renaming PhpAttribute thread) and would also sound more natural. This would also mean that we would rename `PhpCompilerAttribute` to simply `CompilerAttribute`. Best regards, Benas Seliuginas
Re: [PHP-DEV] [RFC] Guard statement
Hello, first of all, thank you for the RFC but this is a big no-no for me. Your arguments as to why it's "okay" to make a BC break doesn't make a lot of sense given the huge "genericness" of the keyword "guard". Laravel's authentication system is used across thousands of projects (if not more) and you can look that up using a simple GitHub search. In fact, even in our internal codebase (our team's, not PHP's) we use it. So, it's plausible that many closed-source projects use it as well. Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
Hello, Not it's not and will likely never be so using `guard` is a really bad idea. Best regaeds, Benas Seliuginas
Re: [PHP-DEV] [VOTE] Constructor Property Promotion
Re: [PHP-DEV] [VOTE] Constructor Property Promotion
Update: I confused myself reading the RFC, sorry! Everything is alright in the examples. >
Re: [PHP-DEV] [VOTE] Constructor Property Promotion
Hello, Thank you for your RFC. It seems that your Attribute examples are not promoted. I suppose that shouldn't be the case? Best regards, Benas Seliuginas
Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
Hey, `guard` would be a keyword this means that all of the classes, interfaces and traits named Guard would be illegal. Therefore Laravel's `Guard` interface would be incompatible with PHP 8 which in turn means thousands of web applications would be too. Best regards, Benas Seliuginas
Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax
Hello,
I think that we SHOULD not introduce a new keyword (e. g. guard) since that
would be a "major major" backwards incompatibility. "Guard" is a really
generic
word and a great example of that is Laravel and their authentication guards.
In general, I don't think that early returns require a seperate syntax
and/or
block statement since a simple `if (...) { return; }` is already sufficient
enough.
Best regards,
Benas Seliuginas
Re: [PHP-DEV] [RFC] Mixed type
Hello, Is there any update on the RFC? Given that there isn't much discussion and 2 weeks have passed, I believe it's safe to move this into a voting phase. Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Attributes v2 RFC Vote is open
I would actually go as far as to say that this is going to be PHP 8 signature feature. Best regards, Benas Seliuginas
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hello, You should ask Benjamin this question as he is the Attributes RFC author. >From my standpoint, I don't really believe we can remove it. As without it, any class would be considered as an attribute - even one that isn't supposed to be. Best regards, Ben.
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hello, > Again, your assumption that just about everyone uses namespaced classes > doesn't take into account closed source projects. I don't care if it's a major > release or not - BC breaks should always be avoided without a major benefit With an introduction of any new language construct, function, class or constant, we don't know whether it affects closed source projects and we can't. So using your own logic, you can't assume that closed source projects use `Attribute` either. Another key term to take into consideration from my email is "in such cases isn't the first priority". That doesn't mean it doesn't matter, so please don't change my words as you please. Since PHP has global namespace reserved, things like implementation details matter much more **in such cases**. > str_contains adds functionality to PHP. We aren't debating whether to add > attribute functionality to PHP, but what to call it. As such, this argument is > an invalid comparison. What I meant by `str_contains()` was its name. There were multiple PHP projects that offered a global helper function called `str_contains()`. As such, introduction of this function was also a name clash for them. > As I said above, I'm ambivalent about this particular issue. However, I get > nervous when I start to see the "Who cares if it breaks stuff" or "Well, they > shouldn't be doing it that way, so screw them" arguments pop up. While the > chances of a BC break might be minimal using "Attribute" - I don't think that > PhpAttribute is an undue burden in an attempt to avoid such instances, nor is > it logically inconsistent with other Php* named classes. Well then you shouldn't take everything so "harshly" and as a debate. There are no "arguments" here, I am simply expressing my own opinion. As for naming inconsistencies, Rowan addressed that already. Best regards, Benas Seliuginas.
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hello, Since your project is just a single example, we still can't make such a bold claim that `\Attribute` is used a lot. While "attribute" is a fairly generic word, just about everyone uses namespaced classes and therefore it's not a huge problem. Moreover, PHP 8 is a major release so BC in such cases isn't the first priority. Also, it's important to mention that the introduction of functions such as `str_contains()` is also a breaking change for some. But the benefits it provides outweigh the 0.1% who may get BC issues. Best regards, Benas Seliuginas
[PHP-DEV] Re: Renaming PhpAttribute to Attribute
Hey internals, Since this is just an implementation detail, Benjamin will submit a new PR himself (after merging Attributes v2 into PHP) to rename `PhpAttribute`. As such, I am not making a separate RFC. Best regards, Benas Seliuginas. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: RFC karma request
Hello, Christoph, thank you so much! Best regards, Benas Seliuginas.
[PHP-DEV] RFC karma request
Hey internals, I need RFC karma for creating and proposing the "Renaming PhpAttribute" RFC. Account's username: moliata Best regards, Benas Seliuginas. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hello, > Speaking on the other note, is there any problem on my side but it doesn't > seem that I am able to register for a PHP wiki account [1]. I keep getting an > error message "That wasn't the answer we were expecting". This is no longer a problem, I successfully registered my wiki account. Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hey, > Like many other things in life, just because you don't see something doesn't > mean that it is certainly not there ;-) I do understand your point and I do agree that there may be some minimal collision but stating that `Attribute` is too generic and will needlessly collide with code in the wild is a fairly bold claim. As such, I asked to back it up. Speaking on the other note, is there any problem on my side but it doesn't seem that I am able to register for a PHP wiki account [1]. I keep getting an error message "That wasn't the answer we were expecting". [1]: https://wiki.php.net/?do=register Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Renaming PhpAttribute to Attribute
Hello, > `Attribute` is certainly too generic, and will needlessly collide with code > in the wild. Could you provide any examples as to where '\Attribute' is being used in the wild? I haven't seen a single project that has an Attribute class and uses the global namespace. > I suggest circling back to the `PHP\` namespace discussion, and having > `PHP\Attribute` if you really have a problem with current naming. In regards to `\PHP` namespace, I believe this is future scope and because it's still not voted into PHP, we should do the things like we always did. I believe that the reasoning behind calling the attribute's class as `PhpAttribute` was because the author wanted to be consistent with PhpToken. But since `PhpToken` was called as such to not raise ambiguity to what kind of a token it is, I believe that the attribute class should be simply named `Attribute` instead. Best regards, Benas Seliuginas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Renaming PhpAttribute to Attribute
Hey internals,
Since it's safe to say that the Attributes v2 RFC has passed, I wanted to
make a separate thread based on the comment by Rowan Tommins in the PHP
namespace policy thread. This is a quote from his comment:
> One prefix doesn't make a trend. "PhpToken" is a different case - it's a
> token of PHP source code, so the prefix isn't anything to do with
> avoiding name collisions, it's a natural clarification.
>
> To be honest, I'd be perfectly happy with the attributes RFC using the
> class name "Attribute", just as we use "Iterator", "Closure",
> "Exception", etc, etc. At which point the whole thing's a non-issue.
I do strongly agree with him and I believe we should rename `\PhpAttribute`
to simply `\Attribute` before the PHP 8 release in order to improve
consistency with other classes and interfaces e. g. Iterator, ArrayAccess,
Countable. It would also make the attribute class definition look more
aesthetically pleasing:
```
>
class Test {}
```
I am ready to make an RFC for this if the replies are mostly positive, so
please, express your opinions!
Best regards,
Benas Seliuginas
P.S: this is my second email account so hopefully it won't get marked as
spam.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
