Re: [PHP-DEV] Make `always true` SPL methods return void

[Jesse Rushlow]

* Disclaimer - I have not thoroughly reviewed the bug report or PR
mentioned.

>From a PHP developers perspective, if I was calling a method that returned
true. I would automatically assume that the method is capable of returning
the inverse of that as well. I see Dan's point of "let sleeping dogs lie"
per say and just adjust the docs. But I'm leaning more towards if a method
can't return false & true, then it should return something else or void.

Thanks
Jesse Rushlow

On Wed, Jun 17, 2020 at 6:18 AM Dan Ackroyd  wrote:

> On Wed, 17 Jun 2020 at 03:00, Gabriel Caruso 
> wrote:
> >
> >  so changing it to `void` and
> > just invoke these methods sounds reasonable to me.
>
> What's the benefit of doing the change?
>
> There will almost certainly be some code somewhere that would be
> broken by changing it, so it needs some benefit for doing it.
>
> I strongly suspect just updating the documentation to be correct, and
> then leaving the code behaving as it has been for the past decade or
> so, would be a better strategy.
>
> cheers
> Dan
> Ack
>
> --
> 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

[Benas IML]

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 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.
>
> 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 

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Larry Garfield]

On Thu, Jun 18, 2020, at 3:49 PM, Andreas Hennings wrote:

> 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)

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.

I am in favor of this RFC for that reason.

--Larry Garfield

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] Re: [RFC][DISCUSSION] Match expression v2

[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.

> 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

--
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

[Andreas Hennings]

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 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.

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)



>
> 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.
>

But here there are actual technical arguments why someone might prefer one
or the other solution.


>
> 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.
>

There are conventions or popular preference, and there are people or
projects which want to do things their own way.
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.

Greetings
Andreas


> > 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 

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Benas IML]

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, even now there are no PSR conventions that specify
>> how and when to write parameter/return/property type hints.
>>
>
> 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 

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Andreas Hennings]

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, even now there are no PSR conventions that specify how and when to
> write parameter/return/property type hints.
>

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.


>
> 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).
>

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.



>
> Last but not least, just to reiterate, the `: void` return type is
> optional and you don't need to specify it.
>

Exactly my point. "Optional" means people will make arbitrary choices and
argue about it, or look for a convention.

Greetings
Andreas



>
> 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 

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Arvids Godjuks]

Hello everyone,

I would like everyone to slow down a bit and give a think about this:

English is not the primary language for the vast majority of people.   are
a thing and a lot of people, actually, work with PHP that either does not
know English at all or, know the basics and rarely have the English skills
to a level that allows them to easily understand subtleties of things.
What you need to consider, that some alternatives that are being talked
about, may not have a translation. Like at all. Here's a case and point for
the Russian language - there is no alternative, as far as I can tell, for a
"blacklist" that has the meaning blacklist or exclude list can be
translated. The only Russian phrase that I know of (and I tried searching
for alternatives) is a literal translation of the phrase "black list".
Anything I could think of just didn't fit - there is just no other word
that describes an "exclude list" - it translates literally to "black list"
anyway.
 Same goes for the Latvian language - the only word we have for it is a
literal translation and nothing else.

And I suspect, it might be the case for many other languages too for a
simple reason - the term came from English first and got adopted one way or
the other into the language because there was no counterpart for it in it.

On the other hand, Russian has a great translation for the "master/slave"
combo - ведущий/ведомый that has 0 association with anything slavery
related. But the literal translation to English is "master/slave", and it
does not translate correctly to "Primary/Secondary" or other alternatives
I've seen around, because it looses all meaning that Russian words describe
for the technical implications of how things work in mechanics, engines and
so on. it's also actually used in aviation too between Commander and Second
Officer. Closest I can translate it is "Leading / One who is led by the
leading".

Just my 0.02$ as food for thought, because PHP is not a regional project.
This is a global project and it's userbase overall, probably, is not
primarily English speakers. A lot of us just revolve around in English
speaking tech bubble, because it is the international language and it is
easiest for everyone who is involved in OSS projects and international
companies. But I'm not, personally, an English speaker - English is my 3rd
language.
 I also live in Russian tech space and it is pretty common to have
developers who do not know English to a level of speaking and/or reading
and relly on documentation translations and those established
industry-standard terms that they know and/or use google translate.

P.S. I just run "exclude list" through google translate into Russian and
Latvian - let's just say that translations were confusing at best because I
can't judge how bad they would be for a person who does not know English
well or at all.

Arvīds Godjuks

+371 26 851 664
arvids.godj...@gmail.com
Skype: psihius
Telegram: @psihius https://t.me/psihius

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Bob Weinand]

> Am 18.06.2020 um 20:24 schrieb Lynn :
> 
> 
> 
> On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand  > wrote:
> P.s. And to be honest, I've never heard from a dark-skinned person that they 
> felt actually oppressed by words like blacklist.
> 
> And here my personal opinion, to be taken with a grain of salt: This whole 
> white- and blacklist discussion is mostly "hey I want to make black people 
> feel more welcome, let me call blacklist bad and condemn everyone not 
> agreeing. Then I have done my good deed" - without having any actual impact 
> on the well-being of dark-skinned people. - That's what it feels like for me, 
> but I'm open to being corrected by those who are actually dark-skinned and 
> impacted by it, in which case I'll immediately retract my last sentence.
> 
> Hi Bob,
> 
> Nobody is talking about oppression when it comes to certain "technical" 
> terms. Please look my post from earlier and look at the tweets I link: 
> https://externals.io/message/110515#110574 
> 
> 
> I can recommend everyone to expand their bubble, as a lot of replies in here 
> show that the bubbles are homogeneous.
> 
> Regards,
> Lynn


Hey,

yes, you are making quite the same point than I did. Maybe I misused the word 
_oppression_ here. But in any case, I fully agree with you.

Bob

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Lynn]

On Thu, Jun 18, 2020 at 3:38 PM Bob Weinand  wrote:

> P.s. And to be honest, I've never heard from a dark-skinned person that
> they felt actually oppressed by words like blacklist.
>
> And here my personal opinion, to be taken with a grain of salt: This whole
> white- and blacklist discussion is mostly "hey I want to make black people
> feel more welcome, let me call blacklist bad and condemn everyone not
> agreeing. Then I have done my good deed" - without having any actual impact
> on the well-being of dark-skinned people. - That's what it feels like for
> me, but I'm open to being corrected by those who are actually dark-skinned
> and impacted by it, in which case I'll immediately retract my last sentence.
>

Hi Bob,

Nobody is talking about oppression when it comes to certain "technical"
terms. Please look my post from earlier and look at the tweets I link:
https://externals.io/message/110515#110574

I can recommend everyone to expand their bubble, as a lot of replies in
here show that the bubbles are homogeneous.

Regards,
Lynn

Re: [PHP-DEV] [RFC] [DISCUSSION] Make constructors and destructors return void

[Benas IML]

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

[Benas IML]

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

[Bob Weinand]

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

[Benas IML]

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 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.
>> > 

[PHP-DEV] VCS Account Request: ilutov

[Ilija Tovilo]

Contribute to PHP :)

-- 
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

[Andreas Hennings]

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 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

[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
"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

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Sara Golemon]

On Wed, Jun 17, 2020 at 7:23 PM Ben Ramsey  wrote:

> I don’t understand this question:
>
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
>
> I recommended this as a front-line question so as to remove any hint of
impropriety about the vote.  For example, where the first round of the
secondary vote sits right now (15/15/4) we only have 44% in favor of any
specific change.  That doesn't nearly meet the 2/3rd requirement.  By
having a "pre-vote" to agree on reselecting the syntax, we have a CLEAR
2/3rd majority saying, "Yes, let's revisit this specific question again".

With that clarified, making the decision on what specific syntax we want is
less contentious.  I had *hoped* that we wouldn't have a party split on the
primary vote, that people who wanted <<>> would still favor a
reconfirmation of the syntax since it was specifically cited that this
would be a point to come back to, but atm that's how things turned out.

Is this a vote to see if we want to re-vote on the attribute syntax? I
> think this is worded awkwardly, and I’m not sure what the outcome of a
> yes or not vote means for this question.
>
> Yeah, the wording is awkward, but so is the situation. /shrug
I hope the above clarifies it.


> If I vote “no,” should I still vote in the secondary vote, or is voting
> “no” effectively the same as choosing `<<>>` for all three choices in
> the secondary vote?
>
> On the primary, you should vote yes if you believe it's worth revisiting
the topic, or no if you feel the people have spoken and alligator syntax
means alligator syntax.
Regardless of primary vote: You should vote on the secondary according to
your preference of syntaxes.

-Sara

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Thu, June 18, 2020 at 7:40 AM Aleksander Machniak  wrote:

> If @@ wins, will a sequence of 3-or-more @ characters forbidden?
> It is not stated in the RFC. I.e. what happens if you write:
>
> @@@ExampleAttribute()
> class Foo
> {
> }
>
> @@@some_function();

Hi Aleksander,

Yes, those examples would be syntax errors if the `@@` proposal is
accepted.

Regards,
Theodore


From: Aleksander Machniak 
Sent: Thursday, June 18, 2020 7:40 AM
To: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

On 18.06.2020 01:59, Theodore Brown wrote:
> Hi internals,
>
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not stated in the RFC. I.e. what happens if you write:

@@@ExampleAttribute()
class Foo
{
}

@@@some_function();

--
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

[Theodore Brown]

On Thu, June 18, 2020 at 8:40 AM Mark Randall wrote:

> On 18/06/2020 00:59, Theodore Brown wrote:
> > I've opened voting on the Shorter Attribute Syntax RFC:
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> 
> I'd be wary of @@ simply because if we do add validation to them,
> we would likely want to use the suppression operator to indicate
> that a class might be omitted (such as if an optional package is
> not installed).
> 
> At which point we're left with @@@ and that's getting into silly-land.

Hi Mark,

Attributes were already designed to be optional, though, so there's
no need to suppress anything. Attribute validation occurs when you
call `ReflectionAttribute::newInstance()`.

Or are you suggesting that we reverse the way this works, and always
validate attributes unless a suppression operator is used? I'm not
convinced this is a good idea - it would require adding a suppression
operator for all the use cases where attribute information is
collected without an attribute class, which changes something that
should be an internal implementation detail to require different
syntax for end-users of a library. Also, it could be confusing if the
suppression operator only prevents autoloading, but doesn't suppress
other warnings. And if it does suppress other warnings, that would
probably not be what developers want in most cases.

Lastly, in my personal opinion combining the suppression operator
with attribute declarations looks like even worse symbol soup with
with the other syntax options. :)

Best regards,
Theodore

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Derick Rethans]

On Wed, 17 Jun 2020, Ben Ramsey wrote:

> > On Jun 17, 2020, at 18:59, Theodore Brown  wrote:
> > 
> > I've opened voting on the Shorter Attribute Syntax RFC: 
> > https://wiki.php.net/rfc/shorter_attribute_syntax
> > 
> > Since all RFCs require a primary vote with a 2/3 majority, there is 
> > a main vote to approve the secondary ranked-choice vote.
> > 
> > For the ranked-choice poll, fill in your first through third syntax 
> > choices, making sure not to select the same syntax more than once. 
> > You don't have to vote for all three options, but please don't leave 
> > gaps.
> > 
> > Voting will end in two weeks, on 2020-07-01.
> 
> I don’t understand this question:
> 
> > Are you okay with re-voting on the attribute syntax for PHP 8.0?
> 
> Is this a vote to see if we want to re-vote on the attribute syntax? I 
> think this is worded awkwardly, and I’m not sure what the outcome of a 
> yes or not vote means for this question.
> 
> If I vote “no,” should I still vote in the secondary vote, or is 
> voting “no” effectively the same as choosing `<<>>` for all three 
> choices in the secondary vote?

> Or, if I vote “no,” does that mean anything I select for the secondary 
> vote is thrown out?

You should vote in all four polls. If you choose "no" in the first one, 
you might still have a preference for the syntax in case the outcome is 
a "yes".

For your syntax preference, you can't pick the same option more than 
once. This is ranked voting.

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

[PHP-DEV] Re: [RFC] [VOTE] Shorter Attribute Syntax

[Mark Randall]

On 18/06/2020 00:59, Theodore Brown wrote:

I've opened voting on the Shorter Attribute Syntax RFC:
https://wiki.php.net/rfc/shorter_attribute_syntax


I'd be wary of @@ simply because if we do add validation to them, we 
would likely want to use the suppression operator to indicate that a 
class might be omitted (such as if an optional package is not installed).


At which point we're left with @@@ and that's getting into silly-land.

Mark Randall
marand...@php.net


--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC][Discussion] Change terminology to ExcludeList

[Bob Weinand]

> Am 18.06.2020 um 00:36 schrieb Jakob Givoni :
> To repeat what has been said many times over now: It's when "black" is
> associated with "bad" in a composite term like "blacklist" we should
> consider being considerate of a group of people who actually have skin
> of that color.
> 
> Best,
> Jakob


TL;DR: Can we please do terminology changes for the right reasons, just like 
the RFC itself is proposing. Thanks.

---

You can also define black as what pure black really is - void of everything - 
no light - nothing. Things we don't see.
And white being light. Things we see.

It does not necessarily need to have a connection with good and bad. You can 
also blacklist legitimate things, but you just don't want to process them right 
now.
The issue is rather that we are talking about "good" and "bad" inputs and then 
connect that to a white- or blacklist. (Because usually the things we do not 
want to see are bad things)

There however is no innate connection from something being black to it being 
bad, rather a coincidence via a couple hops. And only applying in most cases.
For example: "I want to whitelist undesired inputs for logging."

While I see that there is a case for a more unambiguous wording like 
opcache_file_exclude, this matter shall not be about the good-ness or bad-ness 
of the color black.

P.s. And to be honest, I've never heard from a dark-skinned person that they 
felt actually oppressed by words like blacklist.

And here my personal opinion, to be taken with a grain of salt: This whole 
white- and blacklist discussion is mostly "hey I want to make black people feel 
more welcome, let me call blacklist bad and condemn everyone not agreeing. Then 
I have done my good deed" - without having any actual impact on the well-being 
of dark-skinned people. - That's what it feels like for me, but I'm open to 
being corrected by those who are actually dark-skinned and impacted by it, in 
which case I'll immediately retract my last sentence.

Bob
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[PHP Group]

VCS Account Approved: ilutov approved by cmb \o/

-- 
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

[Bob Weinand]

> 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 Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [VOTE] Shorter Attribute Syntax

[Aleksander Machniak]

On 18.06.2020 01:59, Theodore Brown wrote:
> Hi internals,
> 
> I've opened voting on the Shorter Attribute Syntax RFC:
> https://wiki.php.net/rfc/shorter_attribute_syntax

If @@ wins, will a sequence of 3-or-more @ characters forbidden? It is
not stated in the RFC. I.e. what happens if you write:

@@@ExampleAttribute()
class Foo
{
}

@@@some_function();

-- 
Aleksander Machniak
Kolab Groupware Developer[https://kolab.org]
Roundcube Webmail Developer  [https://roundcube.net]

PGP: 19359DC1 # Blog: https://kolabian.wordpress.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

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

[PHP Group]

VCS Account Approved: theodorejb approved by derick \o/

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

[PHP-DEV] VCS Account Request: theodorejb

[Theodore Brown]

I would like the ability to vote on PHP RFCs.

I worked on two successful RFCs for PHP 7.4 (numeric literal separators and the 
curly brace array/string access deprecation), and have also contributed other 
bug fixes and improvements to core.

-- 
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

[Benas IML]

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
>

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Jakob Givoni]

On Thu, Jun 18, 2020 at 9:39 AM Nikita Popov  wrote:
>
>> In a mail that probably went to everyone's spam folder, I asked for
>> opinions on allowing use of .\Foo as an alternative to Foo in the
>> current namespace, thus reducing friction with reserved keywords even
>> more. Any thoughts on that now?
>
>
> How would .\Foo be different from the currently existing namespace\Foo? (Note 
> that "namespace" here is to be taken literally, not as "put the current 
> namespace here").
>

I didn't know you could do that! I don't think I've ever seen it used,
maybe because there's been little advantage over just Foo? I guess it
only matters if you also import Foo?
For what it's worth, .\Foo would be significantly shorter than
namespace\Foo and probably more intuitive to understand as well.
Furthermore, if you were to create a namespace called "Namespace"
(don't judge! ;-)), which I would assume would be possible should this
RFC be implemented, we could avoid namespace\Namespace\Foo :-D

Thanks for the feedback, it was just an idea - could be a new RFC some
other day.

Thanks,
Jakob

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nikita Popov]

On Thu, Jun 18, 2020 at 8:44 AM Claude Pache  wrote:

> Hi,
>
> The following part of the proposal is problematic: Allow keywords in
> definition of classes, functions, const, etc.
>
> class KEYWORD {}interface KEYWORD {}trait KEYWORD {}function KEYWORD() 
> {}const KEYWORD = 0;use Foo as KEYWORD;
>
> Under your proposal, the following code will compile without notice, but
> will have a different behaviour from what the programmer intended:
>
> ```php
> class Int { }
>

This part will still produce an error: "int" is not a reserved keyword, but
it is a reserved class name, and handled by a different mechanism.

const PRINT = 2;
> const YIELD = 3;
>
> function foo(Int $b) {
> return PRINT + YIELD;
> }
> ```
>

Yes, this is the tradeoff :) We trade the ability to use reserved keywords
in controlled situations, with potential confusion for cases like these.

If it is important to allow to define classes, etc. with a keyword as name,
> I suggest to force the programmer to say explicitly “Yes, it is really what
> I want”. For example, something like the following:
>
> ```php
> class namespace\Int { }
>
> const namespace\PRINT = 2;
> ```
>

This syntax doesn't make much sense to me. If we go down that line, I'd
suggest something along the lines of Rust's "raw identifier" concept, which
would allow you to write "const r#PRINT = 2" and "echo r#PRINT". This
syntax would work everywhere identifiers are accepted, e.g. the "namespace
iter\fn" would become "namespace iter\r#fn".

The disadvantage of this approach is that it is not backwards compatible
with PHP 7 and requires more active code change. E.g. the iter\fn example
would "just work" under this RFC, while this approach would require
rewriting the code.

Nikita

Another point which is problematic, is to allow `namespace` as a namespace
> parts, since `namespace\foo`, although interpreted as a namespace-relative
> name, could be intended to be a qualified name by the programmer.
>
> —Claude
>
>
>
>
> Le 16 juin 2020 à 10:52, Nikita Popov  a écrit :
>
> Hi internals,
>
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
>
> https://wiki.php.net/rfc/namespaced_names_as_token
>
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
>
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
>
> Regards,
> Nikita
>
>
>

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Nikita Popov]

On Thu, Jun 18, 2020 at 12:06 AM Jakob Givoni  wrote:

> On Tue, Jun 16, 2020 at 10:52 AM Nikita Popov 
> wrote:
> >
> > Hi internals,
> >
> > Inspired by the recent discussion on reserved keyword reservation, I'd
> like
> > to propose the following RFC:
> >
> > https://wiki.php.net/rfc/namespaced_names_as_token
> >
> > This RFC makes two related changes: Treat namespaced names as a single
> > token, which enables use of reserved keywords inside them. And remove
> > reserved keyword restrictions from various declarations.
> >
> > The RFC comes with a small backwards compatibility break related to names
> > that include whitespace, but will hopefully reduce the backwards
> > compatibility impact of future reserved keyword additions.
> >
> > Regards,
> > Nikita
>
> Love it, thanks Nikita!
>
> In a mail that probably went to everyone's spam folder, I asked for
> opinions on allowing use of .\Foo as an alternative to Foo in the
> current namespace, thus reducing friction with reserved keywords even
> more. Any thoughts on that now?
>

How would .\Foo be different from the currently existing namespace\Foo?
(Note that "namespace" here is to be taken literally, not as "put the
current namespace here").

Nikita

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Marcio Almada]

Hi,

What other language allows this? None that I can think of. Do we want PHP
> doing something it's most closely related languages do not allow?  Why
> don't they allow this?


Most language implementations don't do that because we are all using
parser generators to do the heavy lifting of parsing and these often force
us to pretend our programming languages are context free, and we accept
that for convenience. But most of the programming languages - C, C++,
Python, Ruby, JS, PHP, SQL - are not really context-free.


> What problems are we creating by allowing this?


In that case, this RFC makes it unnecessary to soft reserve words like
`enum`
to avoid BC breaks during PHP8 lifetime.


> I can imagine this would make autoloading functions and constants by
> namespace more complicated, but I'm not sure.


 I don't see how this would be harder with this proposal being accepted.

Ty,
Márcio Almada

Re: [PHP-DEV] [RFC] Treat namespaced names as single token, relax reserved keyword restrictions

[Claude Pache]

Hi,

The following part of the proposal is problematic: Allow keywords in definition 
of classes, functions, const, etc.

class KEYWORD {}
interface KEYWORD {}
trait KEYWORD {}
function KEYWORD() {}
const KEYWORD = 0;
use Foo as KEYWORD;
Under your proposal, the following code will compile without notice, but will 
have a different behaviour from what the programmer intended:

```php
class Int { }

const PRINT = 2;
const YIELD = 3;

function foo(Int $b) {
return PRINT + YIELD;
}
```

If it is important to allow to define classes, etc. with a keyword as name, I 
suggest to force the programmer to say explicitly “Yes, it is really what I 
want”. For example, something like the following:

```php
class namespace\Int { }

const namespace\PRINT = 2;
```

Another point which is problematic, is to allow `namespace` as a namespace 
parts, since `namespace\foo`, although interpreted as a namespace-relative 
name, could be intended to be a qualified name by the programmer.

—Claude




> Le 16 juin 2020 à 10:52, Nikita Popov  a écrit :
> 
> Hi internals,
> 
> Inspired by the recent discussion on reserved keyword reservation, I'd like
> to propose the following RFC:
> 
> https://wiki.php.net/rfc/namespaced_names_as_token
> 
> This RFC makes two related changes: Treat namespaced names as a single
> token, which enables use of reserved keywords inside them. And remove
> reserved keyword restrictions from various declarations.
> 
> The RFC comes with a small backwards compatibility break related to names
> that include whitespace, but will hopefully reduce the backwards
> compatibility impact of future reserved keyword additions.
> 
> Regards,
> Nikita