Re: PSR-16 question

[Chuck Burgess]

Purpose of the interfaces is to make those exact exception types
*catchable*... that's all.

On Feb 24, 2018 13:56, "Alice Wonder"  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+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.
>

-- 
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/CANsgjns%3DWYjjQ43OC0RMkgLSRBUAmrjKGcaPbhU8cyVsgf3HpA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

PSR-16 question

[Alice Wonder]

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

[Niels Braczek]

Am 24.07.2017 um 09:19 schrieb Henrique Rodrigues:

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

First, there are good reasons for the placing of the curly braces - you
see the start and the end of a block immediately without wasting lines.
Actually the current PSR provides better readability than your approach
requiring just one extra line  (I, personally, would prefer to require
curly braces to always be on their own line).

On the other hand, if you have files with thousands of lines, you're
simply doing wrong. Methods should always fit on the screen, a class
should not have more than a few methods, and each class shoud live in
its own file. So, in the worst situation, you'd encounter files with a
few hundred lines.

You will get familiar with the PSR very fast, and it will feel natural
after some time. Just give it a chance.

Regards,
Niels

-- 
| New Stars on the Horizon:  GreenCape  ·  nibralab  ·  laJoom |
| http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
 --

-- 
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/514bf05c-cc59-5b3b-f6b0-1f4cfe1ad167%40bsds.de.
For more options, visit https://groups.google.com/d/optout.

Re: [SUGGESTION] PSR-2

[Alice Wonder]

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.