Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Mel Dafert]

On 10 May 2021 23:57:51 CEST, Christian Schneider  wrote:
>No.
>Outlook is not modern.

While I agree with this (and I also agree with keeping bottom-posting), I feel 
like we could make this easier
for new contributors by giving some examples of which clients to use and how to 
configure them.
What clients are people using that make this convenient?
On desktop, I assume Thunderbird can do this, and my web client (zimbra) also 
can.
On mobile, I've settled with the beta version of K-9 - I don't know of any 
other client that can do this.
(Gmail certainly can't, it can't even send non-HTML mails, and even with K-9 I 
have to remember doing it.)
And please don't say that mobile clients don't matter - if we want to make it 
easy for new people to join,
we should also make sure we support using mobile.

Regards,
Mel

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Sebastian Bergmann]

Am 10.05.2021 um 23:51 schrieb Kamil Tekiela:

Could we drop the bottom-posting rule?


Please: no.

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Stanislav Malyshev]

Hi!

No I don't agree.  People can do whatever is convenient for them.  Some 
will top-post; Some will bottom-post and some will inter-post.  By 
interpost I mean people will try to respond to a post on a point by 
point basis.


The thing is when you alone, you're free to do what is convenient to you 
and ignore the rest. However, here we have a community that needs to 
communicate, and we may want to make it convenient to others to read our 
messages, sometimes to people that are new to the discussion and need 
some context to understand and participate. And our experience on this 
list shows that top-posting does not serve this goal. So we decided to 
ask people to not top-post.


--
Stas Malyshev
smalys...@gmail.com

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

[PHP-DEV] Re: Could we drop the bottom-posting rule?

[Ben Ramsey]

Kamil Tekiela wrote on 5/10/21 16:51:> People [...] read from top to bottom.

This is precisely the reason for bottom-posting. Everything is in a
nice, linear, top-to-bottom progression, with all the context appearing
in a logical order.

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC] Property accessors

[Trevor Rowbotham]

‐‐‐ Original Message ‐‐‐

On Tuesday, May 4th, 2021 at 6:33 AM, Nikita Popov nikita@gmail.com wrote:

> Hi internals,
>
> I'd like to present an RFC for property accessors:
>
> https://wiki.php.net/rfc/property_accessors
>
> Property accessors are like __get() and __set(), but for a single property.
>
> They also support read-only properties and properties with asymmetric
>
> visibility (public read, private write) as a side-effect.
>
> The proposal is modeled after C#-style accessors (also used by Swift), and
>
> syntactically similar to the previous
>
> https://wiki.php.net/rfc/propertygetsetsyntax-v1.2 proposal.
>
> While I put a lot of effort into both the proposal and the implementation,
>
> I've grown increasingly uncertain that this is the right direction for us
>
> to take. The proposal turned out to be significantly more complex than I
>
> originally anticipated (despite reducing the scope to only "get" and "set"
>
> accessors), and I'm sure there are some interactions I still haven't
>
> accounted for. I'm not convinced the value justifies the complexity.
>
> So, while I'm putting this up for discussion, it may be that I will not
>
> pursue landing it. I think a lot of the practical value of this accessors
>
> proposal would be captured by support for read-only (and/or private-write)
>
> properties. This has been discussed (and declined) in the past, but
>
> probably should be revisited.
>
> Regards,
>
> Nikita

Hi,

Thank you for the effort put forth in this RFC. I have a few questions
after having read it.

Will these properties work with the property_exists() function? I don't
see it mentioned in the RFC, and seeing as how the function does not
work with properties defined in __get() and __set(), the answer to this
isn't obvious to me.

The RFC also mentions that calling isset() on a write-only property will
throw an Error exception. Should a new function along the lines of
property_is_readable(), which returns true if the property is readable
in the current scope, (and possibly its mirror function
property_is_writable()) be introduced? Going through the Reflection API
feels overly verbose and error prone to find out if a property is 
readable/writable.

- Trevor

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Deleu]

That would be great!

I had an unpleasant experience with this "rule". You start disagreeing with
someone regarding an RFC and suddenly it becomes a reason to be called out.
Not to mention that when I was pointed to the internal rules and
guidelines, bottom posting is not explicitly listed as a rule, but rather a
suggestion, which then makes it even more annoying to have someone
chastising you about it because it feels much more like the issue is not
really how you're responding to the list, but rather the fact that you're
in disagreement.

On Mon, May 10, 2021, 23:52 Kamil Tekiela  wrote:

> Hi Internals,
>
> Could we drop the bottom-posting rule?
>
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
>
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
>
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
>
> Regards,
> Kamil
>

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Derick Rethans]

On 10 May 2021 22:51:49 BST, Kamil Tekiela  wrote:
>Hi Internals,
>
>Could we drop the bottom-posting rule?

No. 

cheers,
Derick 

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Larry Garfield]

On Mon, May 10, 2021, at 5:08 PM, 😉 Good Guy 😉 wrote:
> On 10/05/2021 23:00, Alain D D Williams wrote:
> > Please do not change - keep bottom posting.
> 
> 
> No I don't agree.  People can do whatever is convenient for them.  Some 
> will top-post; Some will bottom-post and some will inter-post.  By 
> interpost I mean people will try to respond to a post on a point by 
> point basis.
> 
> Frankly anything is acceptable to people as long as it gives a coherent 
> answer that is convincing!
> 
> 
> People should learn to trim some part of the post that they are not 
> responding to like I have done here.

It's true that all three methods have their pros and cons.  The real problem 
comes when mixing both in the same thread, which gets stupidly confusing.

In practice, inter-posting and bottom-posting are more mutually compatible, I 
find, than trying to mix inter-posting with top posting.  I usually interpost 
myself, which is more compatible with bottom-posting.

--Larry Garfield

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[😉 Good Guy 😉]

On 10/05/2021 23:00, Alain D D Williams wrote:

Please do not change - keep bottom posting.



No I don't agree.  People can do whatever is convenient for them.  Some 
will top-post; Some will bottom-post and some will inter-post.  By 
interpost I mean people will try to respond to a post on a point by 
point basis.


Frankly anything is acceptable to people as long as it gives a coherent 
answer that is convincing!



People should learn to trim some part of the post that they are not 
responding to like I have done here.




--

With over 1.3 billion devices now running Windows 10, customer 
satisfaction is higher than any previous version of windows.


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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Alain D D Williams]

On Mon, May 10, 2021 at 10:51:49PM +0100, Kamil Tekiela wrote:

> Could we drop the bottom-posting rule?

Please do not change - keep bottom posting.

> Bottom-posting makes reading the thread much more difficult too.

I really find top posting highly confusing. Bottom (or rather interleaved)
posting makes much more sense.

> Many modern clients are designed to handle top-posting and don't handle
> bottom-posting well.

So: what you mean is that *your* MUA does not handle bottom posting.

-- 
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT 
Lecturer.
+44 (0) 787 668 0256  https://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: 
https://www.phcomp.co.uk/Contact.html
#include 

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

Re: [PHP-DEV] Could we drop the bottom-posting rule?

[Christian Schneider]

No.
Outlook is not modern.
No.
That's not the point, the missing context is.

Sorry, could not resist ;-)

- Chris


> Am 10.05.2021 um 23:51 schrieb Kamil Tekiela :
> 
> Hi Internals,
> 
> Could we drop the bottom-posting rule?
> 
> Almost all new contributors fall into this trap and reply to a thread by
> top-posting, only to get chastised by someone else on the list. It's really
> difficult to remember to delete the default reply. Mail clients don't make
> it easy for us; it's hidden by default. Bottom-posting makes reading the
> thread much more difficult too. The actual reply gets lost in between the
> quoted content. I often get confused about what is new and what was
> quoted. Many modern clients are designed to handle top-posting and don't
> handle bottom-posting well. People are usually used to it and they read
> from top to bottom. I don't know if in the past some mail clients defaulted
> to bottom-posting but right now it just seems like an unnecessary
> annoyance.
> 
> If you want to quote someone then it makes sense to copy a part of the
> message and then add a reply below, but forcing people to remove the
> default reply from the mail client and then add the whole previous message
> on top of your own reply isn't very productive. It wastes time and screen
> space.
> 
> Could we please change this rule or at least stop enforcing it?
> Do people actually have mail clients that don't automatically hide the
> previous conversation? If not, then I think we can let people top-post.
> 
> Regards,
> Kamil

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

[PHP-DEV] Could we drop the bottom-posting rule?

[Kamil Tekiela]

Hi Internals,

Could we drop the bottom-posting rule?

Almost all new contributors fall into this trap and reply to a thread by
top-posting, only to get chastised by someone else on the list. It's really
difficult to remember to delete the default reply. Mail clients don't make
it easy for us; it's hidden by default. Bottom-posting makes reading the
thread much more difficult too. The actual reply gets lost in between the
quoted content. I often get confused about what is new and what was
quoted. Many modern clients are designed to handle top-posting and don't
handle bottom-posting well. People are usually used to it and they read
from top to bottom. I don't know if in the past some mail clients defaulted
to bottom-posting but right now it just seems like an unnecessary
annoyance.

If you want to quote someone then it makes sense to copy a part of the
message and then add a reply below, but forcing people to remove the
default reply from the mail client and then add the whole previous message
on top of your own reply isn't very productive. It wastes time and screen
space.

Could we please change this rule or at least stop enforcing it?
Do people actually have mail clients that don't automatically hide the
previous conversation? If not, then I think we can let people top-post.

Regards,
Kamil

Re: [PHP-DEV] Re: Bugsnet

[Christoph M. Becker]

On 10.05.2021 at 17:10, Nikita Popov wrote:

>  * As was already mentioned, there's no support for security issues, so
> we'd retain bugs.php.net for that purpose, at least for the time being.

But even if bugsnet would no longer be required to file any new tickets,
please keep it in read-only mode.

>  * It's worth noting that issues are per-repository, which means that
> documentation issues will now live in the doc repo(s), and PECL issues in
> the PECL repos. php-src will only have issues relating to php-src
> specifically. This is great.

ACK.

>  * The minimum minor PHP version affected should probably also be specified
> through a label -- I don't personally search issues by version, but other
> people (cmb?) might. If search by version is not common, we can have this
> information only in the issue description. The operating system can be a
> label as well, though we should only add that if the issue is actually
> OS-specific -- this is pretty rare.

I rarely search by version; I think I did that as RM during the
pre-release phase of 7.3.  Most often the version info is pretty
irrelevant, since the issue affects all supported PHP versions.  In my
opinion, having the PHP version in the bug description is good enough
for now; we still can add labels if that turns out to be useful.

>   a) I pretty much never look at bug votes -- though GitHub has thumbs-up,
> thumbs-down as an equivalent there.

I would actually prefer the GH reactions.  The voting feature might
still be broken, anyway.

> TL;DR Yes, I do think switching from bugs.php.net to GitHub issues would be
> beneficial for the project. Details on how to do that need to be ironed
> out, but I think the direction is the right one.

I'm +0.5 on this.

--
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Marco Sirabella]

On Mon, May 10, 2021 at 01:22:46PM -0500, Ben Ramsey wrote:

> Hossein Baghayi wrote on 5/10/21 13:01:
> > On Mon, 10 May 2021 at 21:59, Larry Garfield  wrote:
> > 
> > > 1) Please don't top-post.
> > >
> > >
> > Sorry for top-posting. Didn't know what it means :), also it was kind of my
> > first reply to mailing list.
> 
> 
> https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
> :-)

To be fair, this rule is easy to miss as a "general hint" at the bottom of the
rule page, linked to from [this page](https://www.php.net/mailing-lists.php),
which are also mailing list rules I think?

The rules located on github are the first time I've seen em, thank you for
pointing them out.

Additionally, on the "Mailing List Posting guidelines" (the php.net guide):

> Don't GPG/PGP sign your messages. If you want people to be able to send you
> encrypted email, stick your key-locator in your signature 

Not sure what the rationale for this one is, and I'm not sure I agree with it,
so I'll be breaking it alongside you here. I can't locate the key 0xB9698544
anywhere, though.

-- 
Marco Sirabella


signature.asc
Description: PGP signature

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Ben Ramsey]

Hossein Baghayi wrote on 5/10/21 13:01:
> On Mon, 10 May 2021 at 21:59, Larry Garfield  wrote:
> 
>> 1) Please don't top-post.
>>
>>
> Sorry for top-posting. Didn't know what it means :), also it was kind of my
> first reply to mailing list.


https://github.com/php/php-src/blob/master/docs/mailinglist-rules.md
:-)

Cheers,
Ben



signature.asc
Description: OpenPGP digital signature

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Hossein Baghayi]

On Mon, 10 May 2021 at 21:59, Larry Garfield  wrote:

> 1) Please don't top-post.
>
> 2) The reason is that the old way doesn't provide any way to populate them
> on construction.  The pattern of "assign the arg to the prop in the
> constructor" is stupendously common, and promotion makes it vastly more
> convenient.
>
> For more details:
>
> https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/
>
> The constructor isn't "supposed" to be empty.  It just often is with
> promotion, because the constructor wasn't doing anything else besides
> shuffling its parameters over to properties, which is now automatic.
>
> --Larry Garfield
>
>
Sorry for top-posting. Didn't know what it means :), also it was kind of my
first reply to mailing list.

Yes, I see now. I had forgotten that bit when I replied; apologies.
I guess it makes sense now to end the constructor with a semicolon when it
holds no body.

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Larry Garfield]

On Mon, May 10, 2021, at 12:16 PM, Hossein Baghayi wrote:
> If constructor is supposed to be empty then why are we even bothering with
> construction promoting style? Why aren't we sticking to the old way of
> defining properties?
> Are there any advantages to using construction promoting style?
> 
> I mean sure we could have this:
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> );
> }
> 
> but in my opinion, the old way of defining them is nice and concise:
> class Foo {
> private Bar $bar;
> private Baz $baz;
> }
> 
> What is the point of taking the hard way and then making it convenient?

1) Please don't top-post.

2) The reason is that the old way doesn't provide any way to populate them on 
construction.  The pattern of "assign the arg to the prop in the constructor" 
is stupendously common, and promotion makes it vastly more convenient.

For more details:
https://platform.sh/blog/2020/php-80-feature-focus-constructor-property-promotion/

The constructor isn't "supposed" to be empty.  It just often is with promotion, 
because the constructor wasn't doing anything else besides shuffling its 
parameters over to properties, which is now automatic.

--Larry Garfield

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Sara Golemon]

On Mon, May 10, 2021 at 3:56 AM Marco Pivetta  wrote:

> > Another point to be made here, as far as my interpretation of PSR-12, the
> > curly braces occupy two lines for methods with multiline arguments. So
> for
> > whoever follows PSR-12, it's more like this, with brackets just dangling
> > there across 2 lines.
> >
>
> Given that:
>
>  * `{}` can already represent what you want
>  * the issue is more of a coding-style related topic
>
> I suggest bringing this up in a new PSR instead. Consider that PSR-1, PSR-2
> and PSR-12 were designed pre-PHP-8, so they will need adjustments again,
> but AFAIK nothing has moved yet, since the ecosystem is still adapting to
> the PHP 8 changes (I myself haven't finished adopting it on many of my
> libraries).
>
>
A whole lot of agreeing with Marco here.  The problem is the coding
standard, not the syntax.

Also, as Guilliam said in a later reply, using semicolon already has a
meaning and this contradicts that.  Let's not make the syntax more
confusing purely to avoid updating a PSR that was meant to be a living
standard.

-Sara

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Hossein Baghayi]

If constructor is supposed to be empty then why are we even bothering with
construction promoting style? Why aren't we sticking to the old way of
defining properties?
Are there any advantages to using construction promoting style?

I mean sure we could have this:
class Foo {
public function __construct(
private Bar $bar,
private Baz $baz
);
}

but in my opinion, the old way of defining them is nice and concise:
class Foo {
private Bar $bar;
private Baz $baz;
}

What is the point of taking the hard way and then making it convenient?

On Mon, 10 May 2021 at 21:28, Larry Garfield  wrote:

> On Mon, May 10, 2021, at 9:40 AM, Chase Peeler wrote:
> > On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier <
> guilliam.xav...@gmail.com>
> > wrote:
> >
> > > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
> > > wrote:
> > >
> > > > Hi everyone,
> > > >
> > > > Since constructor property promotion is now implemented, and it looks
> > > > like it could become a widely used feature, I am proposing a small,
> > > > cosmetic change in syntax for constructors in concrete classes to do
> > > > away with empty constructor body.
> > > >
> > > > Here's an example of how this would work:
> > > >
> > > >  > > > namespace App;
> > > >
> > > > class Foo {
> > > > public function __construct(
> > > > private Bar $bar,
> > > > private Baz $baz
> > > > );
> > > > }
> > > >
> > > > Some notes to this:
> > > >
> > > > - Since this is similar to already existing syntax for body-less
> > > > methods, parser should not be affected that much. I hope. I really
> have
> > > > no idea.
> > > > - Syntax would be optional - meaning, you can as well continue using
> > > > empty body, just that in this case the body would be implied empty.
> > > >
> > > > Thoughts?
> > > > Regards,
> > > > - Matīss
> > > >
> > > >
> > > Hi,
> > >
> > > To me `;` means not "empty body" (that's `{}`) but really "no
> definition,
> > > only declaration" (or "no body, only signature", and also "no code
> > > executed"), i.e. an *abstract* method (either explicitly declared so
> in a
> > > class, or implicitly in an interface).
> > >
> > > Granted, property promotion is already special (cannot be used in an
> > > abstract constructor), but it can also be mixed with non-promoted
> > > parameters and body, so I feat that your proposed alternative syntax
> would
> > > bring more confusion than convenience :s
> > >
> > > Regards,
> > >
> > > --
> > > Guilliam Xavier
> > >
> >
> > I'm ambivalent about this proposal, but figured I'd throw out one
> advantage
> > to ; over {}. In my opinion, ending with a semicolon is a very clear way
> of
> > saying there is no body to the method, while having {} could indicate
> that
> > implementation of the body was intended but never actually done. I know
> > that when I'm writing new classes I often will set up the method
> signature
> > but leave the method body empty while I finish the code that utilizes
> that
> > method. I don't know if that is justification for the proposal, but it is
> > one reason why ; might be preferred over {}.
> >
> >
> > --
> > Chase Peeler
> > chasepee...@gmail.com
>
> I agree that in the grand scheme of things this would be a minor matter,
> but aesthetically I would prefer it as well.  The {} annoys me, CS tools or
> no.
>
> Related: I feel the same way about empty-classes and interfaces, which is
> often the case for exceptions where all you're doing is declaring a type.
> I figure that would get even more pushback, though. :-)
>
> As a data point, you can already do the same "semi-colon for no body" for
> foreach, for, and while loops.  I've only ever done it on foreach to runout
> an iterator, but it works on all three today.
>
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Larry Garfield]

On Mon, May 10, 2021, at 9:40 AM, Chase Peeler wrote:
> On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier 
> wrote:
> 
> > On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
> > wrote:
> >
> > > Hi everyone,
> > >
> > > Since constructor property promotion is now implemented, and it looks
> > > like it could become a widely used feature, I am proposing a small,
> > > cosmetic change in syntax for constructors in concrete classes to do
> > > away with empty constructor body.
> > >
> > > Here's an example of how this would work:
> > >
> > >  > > namespace App;
> > >
> > > class Foo {
> > > public function __construct(
> > > private Bar $bar,
> > > private Baz $baz
> > > );
> > > }
> > >
> > > Some notes to this:
> > >
> > > - Since this is similar to already existing syntax for body-less
> > > methods, parser should not be affected that much. I hope. I really have
> > > no idea.
> > > - Syntax would be optional - meaning, you can as well continue using
> > > empty body, just that in this case the body would be implied empty.
> > >
> > > Thoughts?
> > > Regards,
> > > - Matīss
> > >
> > >
> > Hi,
> >
> > To me `;` means not "empty body" (that's `{}`) but really "no definition,
> > only declaration" (or "no body, only signature", and also "no code
> > executed"), i.e. an *abstract* method (either explicitly declared so in a
> > class, or implicitly in an interface).
> >
> > Granted, property promotion is already special (cannot be used in an
> > abstract constructor), but it can also be mixed with non-promoted
> > parameters and body, so I feat that your proposed alternative syntax would
> > bring more confusion than convenience :s
> >
> > Regards,
> >
> > --
> > Guilliam Xavier
> >
> 
> I'm ambivalent about this proposal, but figured I'd throw out one advantage
> to ; over {}. In my opinion, ending with a semicolon is a very clear way of
> saying there is no body to the method, while having {} could indicate that
> implementation of the body was intended but never actually done. I know
> that when I'm writing new classes I often will set up the method signature
> but leave the method body empty while I finish the code that utilizes that
> method. I don't know if that is justification for the proposal, but it is
> one reason why ; might be preferred over {}.
> 
> 
> -- 
> Chase Peeler
> chasepee...@gmail.com

I agree that in the grand scheme of things this would be a minor matter, but 
aesthetically I would prefer it as well.  The {} annoys me, CS tools or no.

Related: I feel the same way about empty-classes and interfaces, which is often 
the case for exceptions where all you're doing is declaring a type.  I figure 
that would get even more pushback, though. :-)

As a data point, you can already do the same "semi-colon for no body" for 
foreach, for, and while loops.  I've only ever done it on foreach to runout an 
iterator, but it works on all three today.

--Larry Garfield

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

Re: [PHP-DEV] Re: Bugsnet

[Rowan Tommins]

On 10/05/2021 16:10, Nikita Popov wrote:

Did I miss anything else that bugs.php.net  does?



The biggest difference I see between GH Issues and every other issue 
tracker I've ever seen is pre-defined fields. Labels can broadly do the 
same job, but they feel very different when managing them, composing 
search queries, and viewing search results.


The fields on the Advanced Search for bugs.php.net are currently:

* Status - GH has only "Open" and "Closed"; we'd probably want a set of 
"Status-..." labels
* Type - "Feature Request" is probably fine as a label; "Documentation 
Problem" would probably be the doc-en issue tracker, but I don't know 
how easily issues can be moved from one project to another during triage
* Project - PHP or PECL; again, possible requirement to move issues 
between projects?
* Package - as you say, this is a long and unwieldy list right now, but 
one that needs to exist in some form (i.e. re-organizing it to a smaller 
list is somewhat orthogonal to moving to a different platform)

* OS - makes sense as optional labels for "Windows-specific" etc
* PHP Version - as you mention, what to do with this depends how people 
use it (and also how reliable it is)

* CVE-ID - irrelevant if security issues are going somewhere else
* Assigned - exists in Github!
* Author email - exists in Github!
* Has patch - redundant
* Has pull request - not sure if you can search on this in Github, or if 
we'd have to add a manual label (again, this is the kind of thing a lot 
of projects maintain bots for)

* Commented by - exists in Github!


Regards,

--
Rowan Tommins
[IMSoP]

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

Re: [PHP-DEV] Re: Bugsnet

[Nikita Popov]

On Mon, May 10, 2021 at 3:29 PM Dan Ackroyd  wrote:

> Hi Joe,
>
> > We have a spam problem on bugsnet
>
> I would snarkily say "maybe accept the PRs from people wanting to work
> on it?", but I realise that ignores the underlying problem, that PHP
> lacks people. And particularly lacks people who can dedicate time to
> understanding, reviewing and saying no to things.
>

Yes, I think this is something people often don't get: It's not just a
matter of finding someone who can implement a change, but also someone who
is willing to review it, and someone who can perform necessary
infrastructure changes, such as server configuration changes or database
migrations. The last part is where things commonly fail.

Even if the plan is to move to a different platform, I'd like to take
> the time to document what is lacking about bugs.php.net currently.
> Please can someone turn on issues for php/web-bugs?
>

Ha, this is a great illustration. You do realize that the bug tracker for
bugs.php.net is bugs.php.net? Under the "General issues - PHP.net Website
problem" category, I believe. However, bugs.php.net is really not suitable
for the kind of use you have in mind. And this also extends to other areas.
For example, for php-src we sometimes use
https://github.com/php/php-tasks/issues to track and coordinate certain
changes, because bugs.php.net is very inconvenient for that purpose.

So, here's my 2c on the proposal. Let me start with issues I see with
bugs.php.net:

 * bugs.php.net is regularly semi-down (slow to the point of being
unusable). Either Derick or myself regularly restart the server to recover
it. I don't believe anyone ever looked into the cause.

 * There is a lot of linkspam, and it's getting worse. I delete a few
comments ever day. On some days it's just a few, on some days it's dozens.
This is something that *can* likely be addressed, but may degrade user
experience further, e.g. with recaptcha, which is notoriously finicky.

 * Next to linkspam, we unfortunately also suffer from hostile user
comments from one Reindl Harald. This user is banned from the mailing list
and our GitHub organization, but we are not able to effectively ban him
from bugs.php.net, because it requires no form of authentication
whatsoever. You can enter an arbitrary email. I think many people don't
appreciate it, but this is actually a ***really big problem***. This user
is consistently and routinely very rude to bug reports, which hurts the
overall reputation of the PHP project. While it should be clear that he
does not represent the PHP project, it still remains a fact that that if
you submit a bug on bugs.php.net, you are quite likely to get some insults
thrown at you. This is not great.

 * I think to resolve the previous point (and linkspam as well), we need to
require authentication on bugs.php.net, which would further degrade user
experience. As part of the git.php.net/master.php.net incident response, we
also discussed whether we could move bugs.php.net to authenticate using
GitHub, now that all PHP contributors need to be part of the PHP GitHub
organization. I think if we wanted to retain bugs.php.net, we'd have to
pursue something in this direction, with all users required to authenticate
through GitHub.

 * For me personally, as a developer with a php.net account, bugs.php.net
is actually a somewhat okay system. I think the main people suffering from
it are bug reporters not affiliated with php.net. One reason is that
there's no good way to manage your reported bugs -- the only thing you get
is a per-bug (!) password to edit it later, bug you can't track bugs you
reported or similar.

 * Bug reports are submitted with incorrect categories very often. I can't
really blame the reporters for that, because there's a *lot* of them, and
they're grouped, so it's really not easy to find the right one (even for
me). This is common to the point that I would consider the inability of the
reporter to specify category/label on GitHub a feature rather than a bug --
this is something that should be done by someone during triage, who is
familiar with the available categories/labels.

 * bugs.php.net does not support checkboxes or edits to the bug
description, which makes it completely unsuitable for tracking issues and
any kind of coordination works (this is part of the reason why the
php-tasks tracker exists).

 * bugs.php.net does not support labels -- only top-level categorization.
For example, we can't mark bugs as "probably easy" or "good first issue" to
give newbies something to chew on.

GitHub issues address most of these concerns, and are tightly integrated
with the pull request workflow. GitHub issues is not the most advanced bug
tracker out there, but the unfortunate truth is that it's still much better
than bugs.php.net. Some thoughts on how our usage would look like:

 * As was already mentioned, there's no support for security issues, so
we'd retain bugs.php.net for that purpose, at least for the time being.

 * Categor

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Chase Peeler]

On Mon, May 10, 2021 at 6:31 AM Guilliam Xavier 
wrote:

> On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
> wrote:
>
> > Hi everyone,
> >
> > Since constructor property promotion is now implemented, and it looks
> > like it could become a widely used feature, I am proposing a small,
> > cosmetic change in syntax for constructors in concrete classes to do
> > away with empty constructor body.
> >
> > Here's an example of how this would work:
> >
> >  > namespace App;
> >
> > class Foo {
> > public function __construct(
> > private Bar $bar,
> > private Baz $baz
> > );
> > }
> >
> > Some notes to this:
> >
> > - Since this is similar to already existing syntax for body-less
> > methods, parser should not be affected that much. I hope. I really have
> > no idea.
> > - Syntax would be optional - meaning, you can as well continue using
> > empty body, just that in this case the body would be implied empty.
> >
> > Thoughts?
> > Regards,
> > - Matīss
> >
> >
> Hi,
>
> To me `;` means not "empty body" (that's `{}`) but really "no definition,
> only declaration" (or "no body, only signature", and also "no code
> executed"), i.e. an *abstract* method (either explicitly declared so in a
> class, or implicitly in an interface).
>
> Granted, property promotion is already special (cannot be used in an
> abstract constructor), but it can also be mixed with non-promoted
> parameters and body, so I feat that your proposed alternative syntax would
> bring more confusion than convenience :s
>
> Regards,
>
> --
> Guilliam Xavier
>

I'm ambivalent about this proposal, but figured I'd throw out one advantage
to ; over {}. In my opinion, ending with a semicolon is a very clear way of
saying there is no body to the method, while having {} could indicate that
implementation of the body was intended but never actually done. I know
that when I'm writing new classes I often will set up the method signature
but leave the method body empty while I finish the code that utilizes that
method. I don't know if that is justification for the proposal, but it is
one reason why ; might be preferred over {}.


-- 
Chase Peeler
chasepee...@gmail.com

Re: [PHP-DEV] Bugsnet

[Christoph M. Becker]

On 10.05.2021 at 15:39, Andreas Heigl wrote:
> Hey All
>
> Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
>> On 09/05/2021 09:48, Joe Watkins wrote:
>>> Morning internals,
>>>
>>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>>> common, daily occurrence. We clearly don't have time for this.
>>>
>>> Quite aside from spam problems, bugsnet is hidden away in a dark
>>> corner of
>>> the internet that requires a special login, doesn't integrate with source
>>> code or our current workflow (very nicely), and doesn't get updated or
>>> developed.
>>
>>
>> So, there are 2 distinct issues: spam from bugsnet (this one can be
>> mitigated by replacing current "solve a problem" challenge by something
>> more sophisticated) and the bugsnet itself being a burden (which can't
>> be solved quickly).
>>
>> Let's separate the two: this way we can have kill the spam in the short
>> term and get enough time to shape out the migration plan if there's a
>> consensus on the matter.
>>
>> What about integrating [recaptcha][1] for now? Integration is rather
>> simple but there are other concerns, e.g. a third-party JS code on the
>> page that accepts security issues.
>
> If so, can we please use something else? Implementing a Honeypot or a
> simple math-captcha isn't that complicated (and I assume that a person
> that can provide a decent bug description can also solve a riddle like
> "Enter the result of 7 plus 2")

We already have a simple math CAPTCHA; it doesn't work, though, if users
switch browser tabs.  Anyhow, I don't think that a CAPTCHA would be
really helpful; we need some real user authentication; this way we could
also block unwanted users.

--
Christoph M. Becker

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

Re: [PHP-DEV] Bugsnet

[Remi Collet]

Le 09/05/2021 à 08:48, Joe Watkins a écrit :


Having moved our workflow to github, now seems to be the time to seriously
consider retiring bugsnet for general use, and using the tools that are
waiting for us - Github Issues.


Please NO

This mean we will drop ownership on all data and history about bug.



Remi

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

Re: [PHP-DEV] Bugsnet

[Andreas Heigl]

Hey All

Am 10.05.21 um 14:44 schrieb Alexander Kurilo via internals:
> On 09/05/2021 09:48, Joe Watkins wrote:
>> Morning internals,
>>
>> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
>> waste time deleting 20 odd messages from bugsnet yesterday and this is a
>> common, daily occurrence. We clearly don't have time for this.
>>
>> Quite aside from spam problems, bugsnet is hidden away in a dark
>> corner of
>> the internet that requires a special login, doesn't integrate with source
>> code or our current workflow (very nicely), and doesn't get updated or
>> developed.
> 
> 
> So, there are 2 distinct issues: spam from bugsnet (this one can be
> mitigated by replacing current "solve a problem" challenge by something
> more sophisticated) and the bugsnet itself being a burden (which can't
> be solved quickly).
> 
> Let's separate the two: this way we can have kill the spam in the short
> term and get enough time to shape out the migration plan if there's a
> consensus on the matter.
> 
> What about integrating [recaptcha][1] for now? Integration is rather
> simple but there are other concerns, e.g. a third-party JS code on the
> page that accepts security issues.

If so, can we please use something else? Implementing a Honeypot or a
simple math-captcha isn't that complicated (and I assume that a person
that can provide a decent bug description can also solve a riddle like
"Enter the result of 7 plus 2")

Thanks!

Andreas
-- 
  ,,,
 (o o)
+-ooO-(_)-Ooo-+
| Andreas Heigl   |
| mailto:andr...@heigl.org  N 50°22'59.5" E 08°23'58" |
| https://andreas.heigl.org   |
+-+
| https://hei.gl/appointmentwithandreas   |
+-+



OpenPGP_signature
Description: OpenPGP digital signature

Re: [PHP-DEV] Re: Bugsnet

[Dan Ackroyd]

Hi Joe,

> We have a spam problem on bugsnet

I would snarkily say "maybe accept the PRs from people wanting to work
on it?", but I realise that ignores the underlying problem, that PHP
lacks people. And particularly lacks people who can dedicate time to
understanding, reviewing and saying no to things.

Even if the plan is to move to a different platform, I'd like to take
the time to document what is lacking about bugs.php.net currently.
Please can someone turn on issues for php/web-bugs?

My two concerns with moving to using other systems would be:

* it'd be really useful to be able to authenticate php.net account
holders on other systems, rather than having to set everyone's
permissions up on each system by hand. I believe Saif may have been
thinking about this a bit.

* the low barrier to 'chipping in' through github issues and PRs have
not been a joyous occasion for me. There is a really high proportion
of "non-productive" contributions e.g. people 'approving PRs' for
libraries they are not involved with, or flaming other users. Although
moving to github issues will solve some annoying problems, that might
be balanced by a larger number of slightly less annoying problems.

But sure, the current situation is rubbish and moving issue tracking
to github seems at least worth trying.

Rowan Tommins wrote:
> In terms of "SaaS vs custom code", it's notable that all three run
> custom bots to add functionality not offered by Github,

Yeah, unfortunately Github has focused more on making the barrier to
using Github low, rather than making it easy to implement access
control for non-enterprise customers.

> It might just be an illusion, but it feels like all three projects have
> a lot more resources to spend on all this than PHP does;

I know for various reasons PHP doesn't have a foundation behind it,
but if there was one, it's the boring stuff that a foundation should
be looking at doing:

* maintaining and improving infrastructure.
* writing documentation and helping people learn PHP internals.
* gathering feedback and summarising it.
* maintaining a list of items that could be worked on.

None of those things are a good fit for being maintained long-term on
an ad-hoc basis.

cheers
Dan
Ack

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

Re: [PHP-DEV] Bugsnet

[Alexander Kurilo via internals]

On 09/05/2021 09:48, Joe Watkins wrote:

Morning internals,

We have a spam problem on bugsnet, it's not a new problem. Nikita had to
waste time deleting 20 odd messages from bugsnet yesterday and this is a
common, daily occurrence. We clearly don't have time for this.

Quite aside from spam problems, bugsnet is hidden away in a dark corner of
the internet that requires a special login, doesn't integrate with source
code or our current workflow (very nicely), and doesn't get updated or
developed.



So, there are 2 distinct issues: spam from bugsnet (this one can be 
mitigated by replacing current "solve a problem" challenge by something 
more sophisticated) and the bugsnet itself being a burden (which can't 
be solved quickly).


Let's separate the two: this way we can have kill the spam in the short 
term and get enough time to shape out the migration plan if there's a 
consensus on the matter.


What about integrating [recaptcha][1] for now? Integration is rather 
simple but there are other concerns, e.g. a third-party JS code on the 
page that accepts security issues.


If it sounds like a way to go, I can help with the integration. Thanks 
to [Dan Ackroyd's pull request][2], setting up environment for torturing 
bugsnet locally is a no-brainer.


[1]: https://www.google.com/recaptcha/about/
[2]: https://github.com/php/web-bugs/pull/91

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

[PHP-DEV] Re: RFC Karma

[Christoph M. Becker]

On 10.05.2021 at 12:22, Michael Maroszek wrote:

> i'd like to request RFC Karma (Username: paresy) to create the RFC for my
> cURL user agent proposal: https://github.com/php/php-src/pull/6834

RFC karma granted.  Best of luck! :)

--
Christoph M. Becker

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Guilliam Xavier]

On Mon, May 10, 2021 at 10:29 AM Matīss Treinis  wrote:

> Hi everyone,
>
> Since constructor property promotion is now implemented, and it looks
> like it could become a widely used feature, I am proposing a small,
> cosmetic change in syntax for constructors in concrete classes to do
> away with empty constructor body.
>
> Here's an example of how this would work:
>
>  namespace App;
>
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> );
> }
>
> Some notes to this:
>
> - Since this is similar to already existing syntax for body-less
> methods, parser should not be affected that much. I hope. I really have
> no idea.
> - Syntax would be optional - meaning, you can as well continue using
> empty body, just that in this case the body would be implied empty.
>
> Thoughts?
> Regards,
> - Matīss
>
>
Hi,

To me `;` means not "empty body" (that's `{}`) but really "no definition,
only declaration" (or "no body, only signature", and also "no code
executed"), i.e. an *abstract* method (either explicitly declared so in a
class, or implicitly in an interface).

Granted, property promotion is already special (cannot be used in an
abstract constructor), but it can also be mixed with non-promoted
parameters and body, so I feat that your proposed alternative syntax would
bring more confusion than convenience :s

Regards,

-- 
Guilliam Xavier

[PHP-DEV] RFC Karma

[Michael Maroszek]

Hi Internals,

i'd like to request RFC Karma (Username: paresy) to create the RFC for my
cURL user agent proposal: https://github.com/php/php-src/pull/6834

Thanks,
Michael

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Marco Pivetta]

Hey Matīss



On Mon, May 10, 2021 at 11:12 AM Matīss Treinis  wrote:

> I don't necessarily agree with this point in particular - I mentioned PSR
> just-by-driveby, since whoever does follow that convention will face this
> issue - but the scope of the proposal is not limited to PSR adopters. It's
> also worth pointing out that PSR is not an "official" coding guideline for
> PHP, and therefore we should probably not limit the scope to it, simply
> because regardless if the brackets are on the same line or not, they are
> still there.
>
> IMO, this is a language issue - topical, cosmetic, and minor - but
> language issue nevertheless, in fact, exactly like the one had for
> attribute syntax.
>
> Let's gather some feedback and see.
>

At language level, `{}` is pretty much "no body" - it's more of an
optimization pass for OpCache at that point.

Adding AST always comes with major complexity for all the ecosystem: since
there is AST isomorphic to the proposal, and it's literally one character
in difference, I don't see a clear advantage.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

I don't necessarily agree with this point in particular - I mentioned PSR
just-by-driveby, since whoever does follow that convention will face this
issue - but the scope of the proposal is not limited to PSR adopters. It's
also worth pointing out that PSR is not an "official" coding guideline for
PHP, and therefore we should probably not limit the scope to it, simply
because regardless if the brackets are on the same line or not, they are
still there.

IMO, this is a language issue - topical, cosmetic, and minor - but language
issue nevertheless, in fact, exactly like the one had for attribute syntax.

Let's gather some feedback and see.

- Matīss


On Mon, May 10, 2021 at 10:55 AM Marco Pivetta  wrote:

>
> On Mon, May 10, 2021 at 10:50 AM Matīss Treinis 
> wrote:
>
>> Hi Marco,
>>
>> I am not sure, that's why I am asking for feedback.
>>
>> I have been converting a ton of code to use constructor property
>> promotion and the absolute majority ends up with the method body being
>> empty. I reckon this could be a nice eye-candy to have, however, it's
>> nothing more than that.
>>
>> Another point to be made here, as far as my interpretation of PSR-12, the
>> curly braces occupy two lines for methods with multiline arguments. So for
>> whoever follows PSR-12, it's more like this, with brackets just dangling
>> there across 2 lines.
>>
>> [...]
>> class Foo {
>> public function __construct(
>> private Bar $bar,
>> private Baz $baz
>> ) {
>> }
>> }
>>
>
> Given that:
>
>  * `{}` can already represent what you want
>  * the issue is more of a coding-style related topic
>
> I suggest bringing this up in a new PSR instead. Consider that PSR-1,
> PSR-2 and PSR-12 were designed pre-PHP-8, so they will need adjustments
> again, but AFAIK nothing has moved yet, since the ecosystem is still
> adapting to the PHP 8 changes (I myself haven't finished adopting it on
> many of my libraries).
>
> If this is relevant to you right now, add an exclusion to your
> `phpcs.xml.dist` instead: easier and less painful than expanding the
> language for such a tiny detail.
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>

[PHP-DEV] Re: Bugsnet

[Derick Rethans]

Hi Joe,

I don't think anybody denies that bugsnet isn't great, and that spam is 
an issue. I would argue that the main reason for the spam is, is that we 
don't require a sign-up. But I think we need to be really careful if 
we'd decide to move to something else.


TLDR: I don't believe GitHub issues is suitable, neither feature wise or 
future-safety wise. We need to be sensible about both items if we 
decided to move to a different issue tracker.


Right now, bugs has several features that GitHub issues doesn't provide: 
multiple statusses, categories (of which bugsnet has a *lot*), and 
dedicated fields for the PHP version etc.

I know that the PHP version can be done through a issue template, and 
that the categories can be done with labels. But in order to represent 
the same rich category information, and hence be able to search on bugs 
in a specific category (such as "DateTime", you'd need a label each for 
each current category.

Having to maintain these labels, and setting them correctly on issues, 
is perhaps going to be more work than removing spam. I'm sure we can 
make it work *somewhat*, but it is going to be a degradation of what 
bugsnet does. On top of that, we'll have to install/configure build 
automation, such as our "quick closes", or the "closed after 3 weeks of 
inactivity".

And I think somebody else mentioned this already, but I am going to 
expect that people will use the issue tracker for support questions as 
well. It has been the case for every GH repository that I had issues 
enabled on.


The other important issue is to consider the continuation of the 
availability of the platform. Bugsnet has been running for 23 years. 
While that unfortunately means that some of the code is that old, it is 
IMO a stellar track record.

Is GitHub Issues going to be around in a way that we want it in another 
23 years? And, if GHI is going a way we don't want it to go in in say 5 
years, is it possible to switch easily to something else?

This isn't really a problem with the code repository itself, as it's 
easy enough to clone and move somewhere else. But that is *not* the case 
for GHI. AFAIK, you can't either import or export easily into/out of it, 
and most definitely not in the rich format that we currently have in 
bugsnet.


I did actually experiment with GitHub Issues for Xdebug, and decided 
that even for that small a project, it wasn't really suitable due to the 
feature set, and that's basically just *me* using it.

I currently use Mantis, which although it has it's minor issues, works 
actually really well. I can host it myself, although they can provide a 
hosted service, and it's actively maintained, and written in PHP. 



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][Draft] Body-less __construct

[Aleksander Machniak]

On 10.05.2021 10:49, Matīss Treinis wrote:
> Another point to be made here, as far as my interpretation of PSR-12, the
> curly braces occupy two lines for methods with multiline arguments. So for
> whoever follows PSR-12, it's more like this, with brackets just dangling
> there across 2 lines.
> 
> [...]
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> ) {
> }
> }

or some would prefer:

class Foo {
public function __construct(
private Bar $bar,
private Baz $baz
) {
// empty
}
}

The question to the proposal. Will this new syntax apply to:
1. all methods
2. all constructors
3. only to constructors with property promotion?

I think 3 makes most sense here and is less contentious. So, just be
sure to specify this in the RFC.

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Marco Pivetta]

On Mon, May 10, 2021 at 10:50 AM Matīss Treinis  wrote:

> Hi Marco,
>
> I am not sure, that's why I am asking for feedback.
>
> I have been converting a ton of code to use constructor property promotion
> and the absolute majority ends up with the method body being empty. I
> reckon this could be a nice eye-candy to have, however, it's nothing more
> than that.
>
> Another point to be made here, as far as my interpretation of PSR-12, the
> curly braces occupy two lines for methods with multiline arguments. So for
> whoever follows PSR-12, it's more like this, with brackets just dangling
> there across 2 lines.
>
> [...]
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> ) {
> }
> }
>

Given that:

 * `{}` can already represent what you want
 * the issue is more of a coding-style related topic

I suggest bringing this up in a new PSR instead. Consider that PSR-1, PSR-2
and PSR-12 were designed pre-PHP-8, so they will need adjustments again,
but AFAIK nothing has moved yet, since the ecosystem is still adapting to
the PHP 8 changes (I myself haven't finished adopting it on many of my
libraries).

If this is relevant to you right now, add an exclusion to your
`phpcs.xml.dist` instead: easier and less painful than expanding the
language for such a tiny detail.

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Ilija Tovilo]

Hi internals

On Mon, May 10, 2021 at 10:32 AM Marco Pivetta  wrote:
>
> Hey Matīss,
>
> This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM
>
> Is the change in AST really necessary, considering that?

The root problem is not that {} is significantly worse than ; but it's
that some cs tools require obnoxious formatting.

```
class Foo {
public function __construct(
private Bar $bar,
private Baz $baz
) {
}
}
```

I agree with Marco, it makes more sense to fix the cs guidelines
rather than to adjust the language just to work around it.

Ilija

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

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

Hi Marco,

I am not sure, that's why I am asking for feedback.

I have been converting a ton of code to use constructor property promotion
and the absolute majority ends up with the method body being empty. I
reckon this could be a nice eye-candy to have, however, it's nothing more
than that.

Another point to be made here, as far as my interpretation of PSR-12, the
curly braces occupy two lines for methods with multiline arguments. So for
whoever follows PSR-12, it's more like this, with brackets just dangling
there across 2 lines.

[...]
class Foo {
public function __construct(
private Bar $bar,
private Baz $baz
) {
}
}



- Matīss


On Mon, May 10, 2021 at 10:31 AM Marco Pivetta  wrote:

> Hey Matīss,
>
> This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM
>
> Is the change in AST really necessary, considering that?
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://ocramius.github.com/
>
>
> On Mon, May 10, 2021 at 10:29 AM Matīss Treinis 
> wrote:
>
>> Hi everyone,
>>
>> Since constructor property promotion is now implemented, and it looks
>> like it could become a widely used feature, I am proposing a small,
>> cosmetic change in syntax for constructors in concrete classes to do
>> away with empty constructor body.
>>
>> Here's an example of how this would work:
>>
>> > namespace App;
>>
>> class Foo {
>> public function __construct(
>> private Bar $bar,
>> private Baz $baz
>> );
>> }
>>
>> Some notes to this:
>>
>> - Since this is similar to already existing syntax for body-less
>> methods, parser should not be affected that much. I hope. I really have
>> no idea.
>> - Syntax would be optional - meaning, you can as well continue using
>> empty body, just that in this case the body would be implied empty.
>>
>> Thoughts?
>> Regards,
>> - Matīss
>>
>>

Re: [PHP-DEV] [RFC][Draft] Body-less __construct

[Marco Pivetta]

Hey Matīss,

This already works by replacing `;` with `{}`: https://3v4l.org/tN4HM

Is the change in AST really necessary, considering that?

Marco Pivetta

http://twitter.com/Ocramius

http://ocramius.github.com/


On Mon, May 10, 2021 at 10:29 AM Matīss Treinis  wrote:

> Hi everyone,
>
> Since constructor property promotion is now implemented, and it looks
> like it could become a widely used feature, I am proposing a small,
> cosmetic change in syntax for constructors in concrete classes to do
> away with empty constructor body.
>
> Here's an example of how this would work:
>
>  namespace App;
>
> class Foo {
> public function __construct(
> private Bar $bar,
> private Baz $baz
> );
> }
>
> Some notes to this:
>
> - Since this is similar to already existing syntax for body-less
> methods, parser should not be affected that much. I hope. I really have
> no idea.
> - Syntax would be optional - meaning, you can as well continue using
> empty body, just that in this case the body would be implied empty.
>
> Thoughts?
> Regards,
> - Matīss
>
>

[PHP-DEV] [RFC][Draft] Body-less __construct

[Matīss Treinis]

Hi everyone,

Since constructor property promotion is now implemented, and it looks 
like it could become a widely used feature, I am proposing a small, 
cosmetic change in syntax for constructors in concrete classes to do 
away with empty constructor body.


Here's an example of how this would work:

- Since this is similar to already existing syntax for body-less 
methods, parser should not be affected that much. I hope. I really have 
no idea.
- Syntax would be optional - meaning, you can as well continue using 
empty body, just that in this case the body would be implied empty.


Thoughts?
Regards,
- Matīss

Re: [PHP-DEV] Bugsnet

[Benjamin Eberlei]

On Sun, May 9, 2021 at 8:49 AM Joe Watkins  wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>

One downside of this "easy access" is that Github Issues tend to get used
as support question forum, at least from my experience on Doctrine it can
easily be 50% of the issues that are support questions. This is much more
work to process than simple spam issues, because there is a human on the
other side who need to be directed towards the proper support channel.

In addition I agree with Rowans assessment that large projects usually have
lots of automation in place on top of Github issues that we would again
need to configure, write or maintain in one way or another.

bugsweb on the other hand is a "classic LAMP" stack application, so maybe
we could look into removing the infrastructure variable from the hosting
equation and look for a PaaS provider? Spam protection third party services
are also available and might potentially be integrated with in a reasonable
amount of time.


> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the r