Courtesy notice of intent to repackage
Hi, I'm working on a project for management of namespaced classes used within WordPress via a PSR-4 autoloader. I am not a WordPress developer, just someone sick of waiting for WordPress to modernize. What I'll be distribution is just a collection of un-modified interfaces from the PSR github so that they are available to classes that want to implement the interfaces. https://github.com/AliceWonderMiscreations/php-fig-iface Yes there's composer, but I don't believe composer belongs on production systems - especially those often managed by a gui in the web application admin panel. This project will probably go nowhere but of course if it did become popular with WordPress admins I would let PHP-FIG manage updates to it if they wanted to. Just wanted to give a headups in case anyone saw it and was confused. I tried to make the README very clear that I am not PHP-FIG but just packaging the interfaces w/o modification. I only put interfaces in it marked as approved, and will periodically check for updates. I just want to encourage the use of PSR interfaces for others writing classes that can be used in a WordPress environment without needing dozens of copies of the same interface individually installed with each plugin that uses it. Thank you for your time. And effort. And interfaces that make life easier. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/a688d630-8590-4ec7-a659-6a174bd72616%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: PSR-12: closing brace MUST NOT be followed by any comment
I guess that's fine. It's just a recommendation, I can choose to ignore
that part of it in my own code.
Just a note though - I don't use an IDE, many people do not.
And while the matching opening { is highlighted, when I have to look up to
see it it distracts my mind from what I'm doing.
So to solve what is a distraction for some creates a required distraction
for others over something that either party could easily adjust to their
own preference with phpcs when working on someone else's code.
On Wednesday, May 16, 2018 at 12:42:47 AM UTC-7, Alessandro Lai wrote:
>
> We discussed that as WG, and we concluded that having a comment in the
> same line of a closing bracket can hinder readability, due to the fact that
> the closing bracket could not be seen; also, not only IDE but basically any
> code editor (even vim) have bracket highlighting.
>
> Il giorno mercoledì 16 maggio 2018 09:26:17 UTC+2, Alice Wonder ha scritto:
>>
>> I do not use an IDE. I do not like them.
>> Typically the only comments I put at the end of a bracket is for end of
>> class and end of function. End of class is not needed when the file only
>> contains a class, but it provides visual consistency.
>>
>> I'm not sure why some people care if there is a comment at end of a
>> closing bracket. Why does it matter to them?
>>
>> On Friday, December 29, 2017 at 1:28:56 AM UTC-8, Alexander Makarov wrote:
>>>
>>> Any good IDE and even simple code editors could highlight matching { and
>>> } so I see no practical use in having a comment.
>>>
>>> On Tuesday, December 26, 2017 at 10:12:47 AM UTC+3, Joe T. wrote:
>>>>
>>>> Refactoring to smaller blocks isn't always practical, particularly with
>>>> older legacy code. i've often used the style described, because
>>>> inevitably,
>>>> some hint that describes the block is more helpful than nothing at all.
>>>> The
>>>> project i currently work with is a nightmare of inconsistent patterns,
>>>> procedural logic crammed into class methods, etc. Just getting things
>>>> documented to understand inner workings of individual *blocks* (let
>>>> alone whole functions) has been a long, slow process.
>>>>
>>>> That said, perhaps moving the "end-of" comment to the line *inside* or
>>>> *after* the terminating *}* can be helpful in most cases, but not
>>>> perfect.
>>>>
>>>> }
>>>> // END foreach($rows)
>>>> }
>>>> // END while ($count)
>>>> // END ridiculously large if ($foo)
>>>> } elseif ($bar) {
>>>> // ...
>>>> }
>>>> // END ridiculously large if/elseif chain
>>>> // END of foo()
>>>> }
>>>> }
>>>>
>>>> There's no ideal solution, given other rules about splitting chained
>>>> controls like "*} else[if ()] {*" because there's no good placement of
>>>> such a comment, nor good way to format it if complying with all the rules.
>>>>
>>>> On Sunday, 3 December 2017 05:07:03 UTC-5, Andreas Möller wrote:
>>>>>
>>>>>
>>>>> I have a style that includes commenting on closing braces of long
>>>>> blocks to help readability. For example,
>>>>>
>>>>> class MyClass
>>>>> {
>>>>>...
>>>>> } // MyClass
>>>>>
>>>>>
>>>>> How about not writing long blocks to help with readability?
>>>>>
>>>>> There are a range of possibilities to refactor your code to avoid the
>>>>> need for comments altogether. See https://refactoring.com/catalog/.
>>>>>
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Andreas
>>>>>
>>>>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/d6dffd82-8657-4410-a6ae-79f13373b849%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: PSR-12: closing brace MUST NOT be followed by any comment
I do not use an IDE. I do not like them.
Typically the only comments I put at the end of a bracket is for end of
class and end of function. End of class is not needed when the file only
contains a class, but it provides visual consistency.
I'm not sure why some people care if there is a comment at end of a closing
bracket. Why does it matter to them?
On Friday, December 29, 2017 at 1:28:56 AM UTC-8, Alexander Makarov wrote:
>
> Any good IDE and even simple code editors could highlight matching { and }
> so I see no practical use in having a comment.
>
> On Tuesday, December 26, 2017 at 10:12:47 AM UTC+3, Joe T. wrote:
>>
>> Refactoring to smaller blocks isn't always practical, particularly with
>> older legacy code. i've often used the style described, because inevitably,
>> some hint that describes the block is more helpful than nothing at all. The
>> project i currently work with is a nightmare of inconsistent patterns,
>> procedural logic crammed into class methods, etc. Just getting things
>> documented to understand inner workings of individual *blocks* (let
>> alone whole functions) has been a long, slow process.
>>
>> That said, perhaps moving the "end-of" comment to the line *inside* or
>> *after* the terminating *}* can be helpful in most cases, but not
>> perfect.
>>
>> }
>> // END foreach($rows)
>> }
>> // END while ($count)
>> // END ridiculously large if ($foo)
>> } elseif ($bar) {
>> // ...
>> }
>> // END ridiculously large if/elseif chain
>> // END of foo()
>> }
>> }
>>
>> There's no ideal solution, given other rules about splitting chained
>> controls like "*} else[if ()] {*" because there's no good placement of
>> such a comment, nor good way to format it if complying with all the rules.
>>
>> On Sunday, 3 December 2017 05:07:03 UTC-5, Andreas Möller wrote:
>>>
>>>
>>> I have a style that includes commenting on closing braces of long blocks
>>> to help readability. For example,
>>>
>>> class MyClass
>>> {
>>>...
>>> } // MyClass
>>>
>>>
>>> How about not writing long blocks to help with readability?
>>>
>>> There are a range of possibilities to refactor your code to avoid the
>>> need for comments altogether. See https://refactoring.com/catalog/.
>>>
>>>
>>> Best regards,
>>>
>>> Andreas
>>>
>>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/0808c262-7893-4bce-a12a-216b7d1db751%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
A suggestion if/when PSR-5 is revived
There should be an option phpdoc header for where information on the latest version of the the package/file can be obtained. It should only appear in the mail file doc comment (that appears before any code except for declaration of stict_types) and my when an automated system makes a call to the url, a GET parameter defining the version of PHP should be standardized when used but not required. Something like @versioncheck: https://www.example.org/whatever.php Clients can use that URL to see if they have the most recent version of the package optionally with ?phpv=7.1.16 appended. The response of the request is beyond the scope of PSR5 but probably should be JSON and if the latest version diffrers for different versions of PHP, the response JSON should be an array of latest versions unless a GET was provided in which case the response may only include what is applicable to that version. Where such a phpdoc header is potentially useful is when plugins are installed in a framework that are not part of a repository updated by the framework itself. It would make a uniform easy mechanism by which such extensions/plugins could be checked to see if they are at the latest version, potentially increasing security when third party plugins are used. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/63137f52-266e-47ac-893b-d2eeb6c554e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Abandoned PSR-5
Is there any desire to bring something like PSR-5 back? There are two reasons why I think there should be some standards related to the doc block. A) For legal reasons, every file needs to have author(s) and license specified in a way that it can be programmatically retrieved. File level comment with @author and @license seems to be the defacto way that is done. B) Code analysis tools often use function comment blocks to determine what type a parameter should be and what type the output should be. Psalm is a good tool for doing that, and since I started using Psalm it has found many bugs of mine that I otherwise would never have triggered myself but I could see how someone using my classes might. But there is some confusion there. I usually specify the types as they would be used in type hinting (e.g. bool or int) but some standards want those same types expressed as boolean or integer. vimeo/psalm seems to like the way I do it, may work with the other I don't know, but that's where a standard like PSR-5 would be useful. It could specify how to indicate the type and then both code analysis tools and programmers can follow the spec. For the most part I think the old PEAR standard is good and most of my checking is done against that, but I just wanted to express that at least one user would be very interested in something like PSR-5 existing. Thank you for your time. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/27026c23-9142-432b-88ad-7f99a87fecde%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Integration of JS and CSS
Okay I have a better expression of what I have in mind, I don't think I communicated it well before, my mind works differently than most and that results in communication problems, I am sorry. https://github.com/AliceWonderMiscreations/ResourceManager That's a github where I am starting to flesh it out. The basic concept is described there, I could retype it here but the Google Groups interface is hard for me to use, it does weird things, markdown is so much easier and github supports markdown. What is there is a synopsis of what I am looking for that I believe would be of huge benefit to web application development as well as improve security by doing things like automatically generating integrity attribute etc. when checksum exists in the script configuration file. With respect to NPM etc. I have used them and do not like them. Similar issues I have with Composer. I think Composer is fantastic for development but I do not believe it is safe for deployment because it really is no different than static linking resulting in vulnerable code. Also there is very little oversight over what goes into packagist. If I was a blackhat I would create Class A and then Class B that depends on A and then C that depends on B and then very useful D that depends on C. Once D had sufficient install base, I just need to put my trojan in A and then soon the trojan would be deployed all over the world. It would be found eventually, but it is too easy to do, hence why I do not like Composer for deployment. I don't mean to offend anyone, it's a fantastic tool for development. The JavaScript managers have same issue and indeed it has happened with them before. -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5c82418d-b739-478e-bc9a-ebb981370d13%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Integration of JS and CSS
What I am going to do is create a reference implementation for a class that
adds JavaScript and CSS to a document that will allow third party JS/CSS to
be packaged separately.
My reference class itself will not be of benefit to 99% of the world
because it will use DOMDocument but from it, hopefully it will demonstrate
what a standard interface could be like, and then if such as PSR is ever
standardized I could then port the reference class to actually implement
what is agreed upon.
Bundling 3rd part JS/CSS into an app for production deployment though is
just fundamentally wrong IMHO and right now that's what has to be done for
both composer and RPM installs.
On Sunday, March 4, 2018 at 3:13:24 PM UTC-8, Alice Wonder wrote:
>
> Yes I am extremely familiar with RPM and have been packaging RPMs since
> the Red Hat 6.0 days (pre Fedora)
>
> But they don't address this issue. For example, the RPMs that exist for
> roundcube mail include jQuery and other 3rd party JS in the roundcube RPM
> itself because their is no standard way to for roundcube to say it needs
> jQuery X.
>
> PHP class dependencies can be in separate packages thanks to autoloaders,
> but not the JavaScript
>
> On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>>
>> Hello,
>>
>> I have a php class that generates an HTML5 audio player with support for
>> WebVTT captions and chapters and is very accessible.
>>
>> It's a personal class, I am not distributing it as FLOSS and I probably
>> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an
>> external file, I do not allow the style attribute in my code) and its own
>> webfont that is used kind of like an image sprite but better IMHO than
>> using an image sprite (for the interface buttons).
>>
>> Anyway one of the things that literally bothers me about so many web
>> applications is they bundle scripts many of which (e.g. jQuery) are third
>> party to the web application.
>>
>> I was thinking it would be good for something *like* PSR-4 to exist for
>> non-php resources.
>>
>> What I mean is Web Application A requires jQuery >= 3 but doesn't need to
>> bundle it itself, where the bundled often often becomes stale.
>>
>> Instead there could be a PSR class interface defined so that when the web
>> application needs to add jQuery to the (x)html document head - it could call
>>
>> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>>
>> Class $whatever would then look in virtual vendor namespace "jQuery" for
>> a script that meets the name definition of "jQuery" with minimum version
>> "3.0" and returns the appropriate URI to add to the script node.
>>
>> For people who use composer it may not make much difference, they will
>> end up with stale version over time (or initially if a composer.lock file
>> is used) just like they often end up with stale unpatched vulnerable
>> versions of class libraries - but for those who actually update their
>> installs periodically (or use an actual package manager which composer is
>> not) it could be of a great benefit.
>>
>> I already do something similar for my own private web apps, it could IMHO
>> be a huge benefit if there was a standardized way of doing it.
>>
>> Thoughts?
>>
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/182782bb-bb29-4a54-8a39-e2972a235d44%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Please make new pkgist release of PSR-16
When one uses
"require": {
"psr/simple-cache": "^1.0"
}
The result when using vimeo/psalm to check the code has errors because of a
bug in the 1.0.0 release that is fixed in master but not fixed in a
released version:
expecting 'null|int|Psr\SimpleCache\DateInterval'
The doc block bug is fixed in master but a stable release was never made
that contains the fix.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/bb39138a-00d4-43a3-91d5-915c9a2fb1aa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Integration of JS and CSS
Yes I am extremely familiar with RPM and have been packaging RPMs since the
Red Hat 6.0 days (pre Fedora)
But they don't address this issue. For example, the RPMs that exist for
roundcube mail include jQuery and other 3rd party JS in the roundcube RPM
itself because their is no standard way to for roundcube to say it needs
jQuery X.
PHP class dependencies can be in separate packages thanks to autoloaders,
but not the JavaScript
On Thursday, March 1, 2018 at 5:29:39 PM UTC-8, Alice Wonder wrote:
>
> Hello,
>
> I have a php class that generates an HTML5 audio player with support for
> WebVTT captions and chapters and is very accessible.
>
> It's a personal class, I am not distributing it as FLOSS and I probably
> won't, but it uses jQuery and its own JavaScript and it's own CSS (in an
> external file, I do not allow the style attribute in my code) and its own
> webfont that is used kind of like an image sprite but better IMHO than
> using an image sprite (for the interface buttons).
>
> Anyway one of the things that literally bothers me about so many web
> applications is they bundle scripts many of which (e.g. jQuery) are third
> party to the web application.
>
> I was thinking it would be good for something *like* PSR-4 to exist for
> non-php resources.
>
> What I mean is Web Application A requires jQuery >= 3 but doesn't need to
> bundle it itself, where the bundled often often becomes stale.
>
> Instead there could be a PSR class interface defined so that when the web
> application needs to add jQuery to the (x)html document head - it could call
>
> $whatever::addJavaScript("jQuery:jQuery", "3.0");
>
> Class $whatever would then look in virtual vendor namespace "jQuery" for a
> script that meets the name definition of "jQuery" with minimum version
> "3.0" and returns the appropriate URI to add to the script node.
>
> For people who use composer it may not make much difference, they will end
> up with stale version over time (or initially if a composer.lock file is
> used) just like they often end up with stale unpatched vulnerable versions
> of class libraries - but for those who actually update their installs
> periodically (or use an actual package manager which composer is not) it
> could be of a great benefit.
>
> I already do something similar for my own private web apps, it could IMHO
> be a huge benefit if there was a standardized way of doing it.
>
> Thoughts?
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/212bd45f-816d-4287-a79c-5d6735fe1427%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Integration of JS and CSS
Hello,
I have a php class that generates an HTML5 audio player with support for
WebVTT captions and chapters and is very accessible.
It's a personal class, I am not distributing it as FLOSS and I probably
won't, but it uses jQuery and its own JavaScript and it's own CSS (in an
external file, I do not allow the style attribute in my code) and its own
webfont that is used kind of like an image sprite but better IMHO than
using an image sprite (for the interface buttons).
Anyway one of the things that literally bothers me about so many web
applications is they bundle scripts many of which (e.g. jQuery) are third
party to the web application.
I was thinking it would be good for something *like* PSR-4 to exist for
non-php resources.
What I mean is Web Application A requires jQuery >= 3 but doesn't need to
bundle it itself, where the bundled often often becomes stale.
Instead there could be a PSR class interface defined so that when the web
application needs to add jQuery to the (x)html document head - it could call
$whatever::addJavaScript("jQuery:jQuery", "3.0");
Class $whatever would then look in virtual vendor namespace "jQuery" for a
script that meets the name definition of "jQuery" with minimum version
"3.0" and returns the appropriate URI to add to the script node.
For people who use composer it may not make much difference, they will end
up with stale version over time (or initially if a composer.lock file is
used) just like they often end up with stale unpatched vulnerable versions
of class libraries - but for those who actually update their installs
periodically (or use an actual package manager which composer is not) it
could be of a great benefit.
I already do something similar for my own private web apps, it could IMHO
be a huge benefit if there was a standardized way of doing it.
Thoughts?
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/7c6c34a4-9bfc-4742-8bea-3a5a257e7eb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: PSR-16 question
Thank you, I got it figured out. I have not personally worked with implementing interfaces before, had seen classes that implemented them but wasn't aware they could both extend another class *and* implement an interface. So it was ignorance confusing me. I have it working now extending \InvalidArgumentException which from the name of the interface is what I'm guessing was intended, which lets me catch them with \InvalidArgumentException which I'm guessing is also what was intended. On Monday, February 26, 2018 at 3:35:15 AM UTC-8, Paul Dragoonis wrote: > > Hi Alice, > > It's recommended not to throw \Exception but throw your own cache > exception class, which implement's PSR-16's CacheException. > > """ > use Psr\SimpleCache\CacheException; > class MyProjectsCacheException extends Exception implements CacheException > """ > > This way you'll be able to continue to catch(Exception $e) in general, but > also be specific and typehint on CacheException if you need to. > > I hope that answers your question. > > Many thanks, > Paul > > > On Sat, Feb 24, 2018 at 8:02 PM, Chuck Burgess <demon...@gmail.com > > wrote: > >> Purpose of the interfaces is to make those exact exception types >> *catchable*... that's all. >> >> On Feb 24, 2018 13:56, "Alice Wonder" <alicedo...@gmail.com > >> wrote: >> >>> I have a personal cache class that would be cake to port to use PSR-16, >>> but PSR-16 also defines two exception interfaces. >>> >>> Is it really necessary I extend those two interfaces rather than extend >>> a different exception interface? >>> >>> zetacomponents base package has an abstract exceptions class I sometimes >>> extend. >>> >>> If I have to implement the interface in PSR-16 to be compliant than to >>> use that abstract class I would have to change that abstract class to >>> implement the PSR-16 exception interfaces instead of just \Exception and it >>> strikes me that that is just, well, absurd since the PSR-16 interfaces >>> don't do anything or even extend \Exception. >>> >>> Am I not understanding the purpose of those interfaces? >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PHP Framework Interoperability Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to php-fig+u...@googlegroups.com . >>> To post to this group, send email to php...@googlegroups.com >>> . >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/85594732-4a0a-4058-a263-a48db4738e70%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/php-fig/85594732-4a0a-4058-a263-a48db4738e70%40googlegroups.com?utm_medium=email_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "PHP Framework Interoperability Group" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to php-fig+u...@googlegroups.com . >> To post to this group, send email to php...@googlegroups.com >> . >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/CANsgjns%3DWYjjQ43OC0RMkgLSRBUAmrjKGcaPbhU8cyVsgf3HpA%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/php-fig/CANsgjns%3DWYjjQ43OC0RMkgLSRBUAmrjKGcaPbhU8cyVsgf3HpA%40mail.gmail.com?utm_medium=email_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/2a369451-f576-4e60-9b33-15085c257cb6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
PSR-16 question
I have a personal cache class that would be cake to port to use PSR-16, but PSR-16 also defines two exception interfaces. Is it really necessary I extend those two interfaces rather than extend a different exception interface? zetacomponents base package has an abstract exceptions class I sometimes extend. If I have to implement the interface in PSR-16 to be compliant than to use that abstract class I would have to change that abstract class to implement the PSR-16 exception interfaces instead of just \Exception and it strikes me that that is just, well, absurd since the PSR-16 interfaces don't do anything or even extend \Exception. Am I not understanding the purpose of those interfaces? -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/85594732-4a0a-4058-a263-a48db4738e70%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [SUGGESTION] PSR-2
I prefer the first. I also prefer two spaces over four. When I am working
in a term window, space is an issue. Extra newlines means I can see fewer
lines at a time and extra 4 space tabs quickly forces the end of a line
horizontally out of my view.
I know most people like the second (and 4 spaces for tabs) but honestly -
when working on a project with others, use what the project specifies but
for your own, do what works best for you. For me - that's not a lot of
newlines and two spaces for the tab.
On Monday, July 24, 2017 at 12:19:22 AM UTC-7, Henrique Rodrigues wrote:
>
> Hello, I'm a beginner in the group and I'm a computer student, I recently
> met PHP-FIG, every time I program, I try to adopt good programming
> practices, when I start studying PSR, I saw things I already practiced
>
> In PSR-2, there is something that, in my opinion, is not very practical,
> the "if, elseif and else".
>
> Original Pattern
>
> if ($a === $b) {
> bar();
> } elseif ($a > $b) {
> $foo->bar($arg1);
> } else {
> BazClass::bar($arg2, $arg3);
> }
>
>
>
> Template that I use
>
> if ($a === $b) {
> bar();}
> elseif ($a > $b) {
> $foo->bar($arg1);}
> else {
> BazClass::bar($arg2, $arg3);}
>
>
>
>
> The original standard in my view on files that have thousands of lines of
> code gets a bit confusing and not organized in my opinion, I would like to
> know from the community what you think of this?
>
> OBS: Sorry for my English, because my native language is not English, and
> my knowledge of English is much more technical.
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/d071699a-dd00-4fb4-850f-b24a004af368%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
