Clarify a point in README.md wrt PSR-5 status and PSR-7 status

[sten0]

Hi,

I'm preparing an update for Debian's packaging of php-mode. While working on improving/update the package's long description I noticed "PHP Mode does yet not fully support the PSR-5: PHPDoc (Draft)" in README.md. Is this still current, is it still a project goal, or has the focus has shifted to PSR-7? If it has shifted, what is the status of PHP Mode's PSR-7 support?

Thanks,
Nicholas

[ejmr]

Heyo Nicholas,

...is [PSR-5, PHPDoc support] still a project goal?

As far as I know, yes. But I have to immediately qualify that statement with the fact that I am no longer an active maintainer or developer on the project. I try to catch up on what's going on with the project about once every two--three weeks, and even more infrequently I respond to issues. With all that said, though, I have not seen any mention of not finishing support for PSR-5. My impression is that for most users the current support is "good enough", and I do not get the feeling that anyone is treating it as a high priority at the moment.

There is a relevant issue elsewhere about writing a project roadmap. In light of this issue, I think we (i.e. @emacs-php) should describe the priorities about supporting the various PSR's, where appropriate.

...what is the status of PHP Mode's PSR-7 support?

This? At a glance, it looks like something outside the current scope of PHP Mode. Or I guess more specifically, it's not obvious to me what PHP Mode should even do in order to say it supports PSR-7. If you or anyone else has any ideas or suggestions I know the developers would appreciate them, and if so then thank you in advanced for the feedback.

-- ejmr

[sten0]

Hi Eric,

On Sun, Jul 15, 2018 at 04:20:44PM -0700, Eric James Michael Ritz wrote: Heyo Nicholas, ...is [PSR-5, PHPDoc support] still a project goal? As far as I know, yes. But I have to immediately qualify that statement with the fact that I am no longer an active maintainer or developer on the project. I try to catch up on what's going on with the project about once every two--three weeks, and even more infrequently I respond to issues. With all that said, though, I have not seen any mention of not finishing support for PSR-5. My impression is that for most users the current support is "good enough", and I do not get the feeling that anyone is treating it as a high priority at the moment.

Thank you for replying so quickly! :-) Hm, I looked into PSR-5 a bit more and found that its status is now "abandoned" https://www.php-fig.org/psr/ Given this, it especially makes sense that this wouldn't be a high priority project goal!

There is [1]a relevant issue elsewhere about writing a project roadmap. In light of this issue, I think we (i.e. ***@***.***) should describe the priorities about supporting the various PSR's, where appropriate.

Yes, that would be valuable.

...what is the status of PHP Mode's PSR-7 support? [3]This? At a glance, it looks like something outside the current scope of PHP Mode. Or I guess more specifically, it's not obvious to me what PHP Mode should even do in order to say it supports PSR-7. If you or anyone else has any ideas or suggestions I know the developers would appreciate them, and if so then thank you in advanced for the feedback.

Honestly I'm not sure...maybe something like this: https://github.com/oscarotero/psr7-unitesting Cheers, Nicholas

[zonuexe]

@sten0 Thank you, I am reliable on your help.

Indeed the standard is ABANDONED, but since we already implemented by some implementations(Phan, PHPStan), it is worth supporting PHP Mode.

(I previously wrote a report on the PSR-5 and de facto standard of PHPDoc. But it is written in Japanese: https://qiita.com/tadsan/items/72b02339d12120ca37d7)

PSRs are classified into three types: AUTOLOADING, INTERFACES, and CODING STYLES.
For php-mode there are not important except for PSR-2 and PSR-5 (and PSR-12 being reviewed).

@ejmr
Sorry for lack of communication for a while. I spent my time preparing two local PHP conferences in Japan for the past two months. I came back from the trip today, so I can use the time for @emacs-php.

[ejmr]

@sten0

Thank you for the link to that GitHub project re. PSR-7 unit-testing. I will need to read PSR-7 carefully, but my initial impression, and the impression from also looking at that project, is that PSR-7 does not introduce anything to the language of PHP; that is, no new syntax we need to worry about parsing, control structures that would introduce new levels of indentation, etc. That is not to say that PHP Mode should not do anything with regard to PSR-7 support, only that it did not have any obvious "big changes" PHP Mode would need to support with new code. I also admit that is a completely arbitrary evaluation, and again, I would need to read every word of PSR-7 in detail. The links you've provided give us all valuable context and examples, so again, thank you.

@zonuexe

I previously wrote a report on the PSR-5 and de facto standard of PHPDoc. But it is written in Japanese.

Just in passing, since I don't do nearly as much programming nowadays, one useful contribution I could make is to translate any such documents to English for the @emacs-php group if you feel like their contents would be useful to the group at large.

Sorry for lack of communication for a while. I spent my time preparing two local PHP conferences in Japan for the past two months.

No need to apologize. Do you intend to go to PHPCon in December? I plan on going if possible. Actually I already had plans to visit Japan near the end of the year for other personal reasons, and then coincidentally saw that conference. I have never gone to a conference specifically about PHP, but if I can make it to that one I think it would be a fun experience.

[zonuexe]

Do you intend to go to PHPCon in December?

of course! I will participate as a speaker or staff. I am excited to meet @ejmr!

[ejmr]

I will do my best to be there. I will mostly be residing in Nagoya but I will make the trip to the conference.

[jwdunne]

@ejmr From my understanding, PSR-7 is a standard for HTTP messages (i.e requests, responses, headers) along with a bunch of interfaces. There is nothing in terms of formatting or syntax in the spec. I've worked on evaluating and implementing this PSR - PHP Mode worked fine as is from implementation to testing so there isn't anything that PHP mode needs to do.

…

On 18 Jul 2018, at 19:56, Eric James Michael Ritz ***@***.***> wrote: @sten0 <https://github.com/sten0> Thank you for the link to that GitHub project re. PSR-7 unit-testing. I will need to read PSR-7 carefully, but my initial impression, and the impression from also looking at that project, is that PSR-7 does not introduce anything to the language of PHP; that is, no new syntax we need to worry about parsing, control structures that would introduce new levels of indentation, etc. That is not to say that PHP Mode should not do anything with regard to PSR-7 support, only that it did not have any obvious "big changes" PHP Mode would need to support with new code. I also admit that is a completely arbitrary evaluation, and again, I would need to read every word of PSR-7 in detail. The links you've provided give us all valuable context and examples, so again, thank you. @zonuexe <https://github.com/zonuexe> I previously wrote a report on the PSR-5 and de facto standard of PHPDoc. But it is written in Japanese. Just in passing, since I don't do nearly as much programming nowadays, one useful contribution I could make is to translate any such documents to English for the @emacs-php <https://github.com/emacs-php> group if you feel like their contents would be useful to the group at large. Sorry for lack of communication for a while. I spent my time preparing two local PHP conferences in Japan for the past two months. No need to apologize. Do you intend to go to PHPCon <http://phpcon.php.gr.jp/2018/> in December? I plan on going if possible. Actually I already had plans to visit Japan near the end of the year for other personal reasons, and then coincidentally saw that conference. I have never gone to a conference specifically about PHP, but if I can make it to that one I think it would be a fun experience. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#473 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAjP2mHCv60gcWRbFCTOisLODbkxRy-qks5uH4T7gaJpZM4VQDJT>.

[sten0]

Hi @ejmr,

On Tue, Jul 17, 2018 at 11:21:14PM -0700, USAMI Kenta wrote: ***@***.*** Thank you, I am reliable on your help. Indeed the standard is ABANDONED, but since we already implemented by some implementations(Phan, PHPStan), it is worth supporting PHP Mode. (I previously wrote a report on the PSR-5 and de facto standard of PHPDoc. But it is written in Japanese: [2]https://qiita.com/tadsan/items/72b02339d12120ca37d7) PSRs are classified into three types: AUTOLOADING, INTERFACES, and CODING STYLES. For php-mode there are not important except for PSR-2 and PSR-5 (and PSR-12 being reviewed).

Sorry for the delay, and thank you for clearing this up. Ok, I'll make sure that the package declares PSR-2 and PSR-5 support. Cheers, Nicholas

[sten0]

@ejmr @jwdunne

> On 18 Jul 2018, at 19:56, Eric James Michael Ritz ***@***.***> wrote: > > @sten0 <https://github.com/sten0> > Thank you for the link to that GitHub project re. PSR-7 unit-testing. I will need to read PSR-7 carefully, but my initial impression, and the impression from also looking at that project, is that PSR-7 does not introduce anything to the language of PHP; that is, no new syntax we need to worry about parsing, control structures that would introduce new levels of indentation, etc. That is not to say that PHP Mode should not do anything with regard to PSR-7 support, only that it did not have any obvious "big changes" PHP Mode would need to support with new code. I also admit that is a completely arbitrary evaluation, and again, I would need to read every word of PSR-7 in detail. The links you've provided give us all valuable context and examples, so again, thank you. On Fri, Jul 20, 2018 at 01:37:18AM -0700, James W Dunne wrote: @ejmr From my understanding, PSR-7 is a standard for HTTP messages (i.e requests, responses, headers) along with a bunch of interfaces. There is nothing in terms of formatting or syntax in the spec. I've worked on evaluating and implementing this PSR - PHP Mode worked fine as is from implementation to testing so there isn't anything that PHP mode needs to do.

Sorry for the delay, and thank you for your replies. Maybe I'm wrong, but I thought it might be possible to do something (broadly speaking) like schema validation of a class or buffer-region that produces a PHP stream, to determine if that stream is a PSR-7-compliant stream. If I'm wrong, or if that wouldn't be sufficiently useful, please feel free to close this issue. It sounds like I'm wrong ;-) Cheers, Nicholas

[ejmr]

...schema validation of a class or buffer-region that produces a PHP stream, to determine if that stream is a PSR-7 compliarnt stream.

That sounds like a cool feature. We can selectively execute chunks of PHP code, so maybe that would be one way to approach such a feature if anyone wants to implement it.

It sounds like I'm wrong ;-)

You brought a useful topic to our attention. That is never "wrong", or in fact anything but great.

--ejmr

[zonuexe]

@sten0

Maybe I'm wrong, but I thought it might be possible to do something (broadly speaking)
like schema validation of a class or buffer-region that produces a PHP stream, to determine if that stream is a PSR-7-compliant stream.

PHP is generally a "dynamic language", so static analysis is outside the scope of the language processing system. Therefore, there are several PHP static analysis tool projects, PHPStan is one of them.

The commercial product popular in that field is PhpStorm, but flycheck-phpstan can do the same level of error checking as that.

[zonuexe]

@sten0
I wrote information about PSR-5 support in #478.
(In conclusion we will not implement them immediately.)
A link to that information has been added to the README.

Is this the information you needed in this issue?