date:20181126

Re: Symfony leaving PHP-FIG

2018-11-26 Thread Chris Tankersley

I echo Joe's sentiments. While I'm always sad to see a project leave, there is 
never a requirement to implement any of the PSRs. While we are starting to dig 
into more implementation-specific PSRs, I feel like those are good places for 
projects to step up and work with the Working Groups that they feel affect them.

That being said, thank you for the time and effort put into the group.
-Chris

On Nov 26 2018, at 1:26 pm, Joe Ferguson  wrote:
>
> Sad to see Symfony leaving. While implementation was never a requirement, I’d 
> much rather see you name a replacement instead of leaving FIG altogether.
>
> Thanks for contributions.
>
> --
> - Joe Ferguson
> JoeFerguson.me
> osmihelp.org
>
> On Nov 26, 2018, 12:20 -0600, Fabien Potencier , 
> wrote:
> > Most of you have probably seen my pull request to remove Symfony as a 
> > member project,
> > and I wanted to follow up and clarify a few things.
> >
> > Symfony has always aimed to promote and follow various standards, and many 
> > of the
> > PSRs have been absolutely instrumental in advancing PHP in this direction. 
> > Symfony
> > has supported, encouraged, and implemented these PSR's - and the people 
> > involved
> > deserve a thanks for their efforts.
> >
> > However, I want to confirm that Symfony would like to be removed as a 
> > member project.
> > Interoperability & standards are still as important as ever, but we believe 
> > that the
> > direction the group is taking is diverging from Symfony's interpretation of 
> > the
> > original mission statement written on the PHP-FIG's homepage:
> >
> > "We're a group of established PHP projects whose goal is to talk about
> > commonalities between our projects and find ways we can work better 
> > together."
> >
> > We will continue to implement the PSRs relevant for the Symfony project.
> >
> > Thank you for your understanding,
> > Fabien
> >
> >
> > --
> > 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 
> > (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/0?redirect=mailto%3Aphp-fig%2Bunsubscribe%40googlegroups.com=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> > To post to this group, send email to php-fig@googlegroups.com 
> > (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/1?redirect=mailto%3Aphp-fig%40googlegroups.com=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/php-fig/ba11b567-11d6-4431-ba82-9964da20ff3c%40googlegroups.com
> >  
> > (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/2?redirect=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fphp-fig%2Fba11b567-11d6-4431-ba82-9964da20ff3c%2540googlegroups.com%3Futm_medium%3Demail%26utm_source%3Dfooter=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> > For more options, visit https://groups.google.com/d/optout 
> > (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/3?redirect=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
>
>
>
> --
> 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 
> (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/4?redirect=mailto%3Aphp-fig%2Bunsubscribe%40googlegroups.com=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> To post to this group, send email to php-fig@googlegroups.com 
> (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/5?redirect=mailto%3Aphp-fig%40googlegroups.com=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/php-fig/458150ed-0d64-425d-ac2b-ce4c05eba97f%40Spark
>  
> (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/6?redirect=https%3A%2F%2Fgroups.google.com%2Fd%2Fmsgid%2Fphp-fig%2F458150ed-0d64-425d-ac2b-ce4c05eba97f%2540Spark%3Futm_medium%3Demail%26utm_source%3Dfooter=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
> For more options, visit https://groups.google.com/d/optout 
> (https://link.getmailspring.com/link/1543256904.local-fa9a07e7-d04e-v1.5.2-31660...@getmailspring.com/7?redirect=https%3A%2F%2Fgroups.google.com%2Fd%2Foptout=cGhwLWZpZ0Bnb29nbGVncm91cHMuY29t).
>

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

Re: Symfony leaving PHP-FIG

2018-11-26 Thread Joe Ferguson

Sad to see Symfony leaving. While implementation was never a requirement, I’d 
much rather see you name a replacement instead of leaving FIG altogether.

Thanks for contributions.

--
- Joe Ferguson
JoeFerguson.me
osmihelp.org
On Nov 26, 2018, 12:20 -0600, Fabien Potencier , 
wrote:
> Most of you have probably seen my pull request to remove Symfony as a member 
> project,
> and I wanted to follow up and clarify a few things.
>
> Symfony has always aimed to promote and follow various standards, and many of 
> the
> PSRs have been absolutely instrumental in advancing PHP in this direction. 
> Symfony
> has supported, encouraged, and implemented these PSR's - and the people 
> involved
> deserve a thanks for their efforts.
>
> However, I want to confirm that Symfony would like to be removed as a member 
> project.
> Interoperability & standards are still as important as ever, but we believe 
> that the
> direction the group is taking is diverging from Symfony's interpretation of 
> the
> original mission statement written on the PHP-FIG's homepage:
>
> "We're a group of established PHP projects whose goal is to talk about
> commonalities between our projects and find ways we can work better together."
>
> We will continue to implement the PSRs relevant for the Symfony project.
>
> Thank you for your understanding,
> Fabien
>
> --
> 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/ba11b567-11d6-4431-ba82-9964da20ff3c%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/458150ed-0d64-425d-ac2b-ce4c05eba97f%40Spark.
For more options, visit https://groups.google.com/d/optout.

Symfony leaving PHP-FIG

2018-11-26 Thread Fabien Potencier

Most of you have probably seen my pull request to remove Symfony as a
member project,
and I wanted to follow up and clarify a few things.

Symfony has always aimed to promote and follow various standards, and many
of the
PSRs have been absolutely instrumental in advancing PHP in this direction.
Symfony
has supported, encouraged, and implemented these PSR's - and the people
involved
deserve a thanks for their efforts.

However, I want to confirm that Symfony would like to be removed as a
member project.
Interoperability & standards are still as important as ever, but we believe
that the
direction the group is taking is diverging from Symfony's interpretation of
the
original mission statement written on the PHP-FIG's homepage:

"We're a group of established PHP projects whose goal is to talk about
commonalities between our projects and find ways we can work better
together."

We will continue to implement the PSRs relevant for the Symfony project.

Thank you for your understanding,
Fabien

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Nicholas Ruunu

Yeah, that's a valid point.
In PHPStorm you can just overwrite `@throws` with nothing, or with anything
that's not an exception like `-` and it won't squawk.
What about just doing something like that?

On 26 November 2018 at 15:16:12, Alexandru Pătrănescu (dreal...@gmail.com)
wrote:

A RemoteStringLoader implementation that will fetch the string from a remote
location and then use StringLoader by composition.

Alex

On Mon, Nov 26, 2018 at 3:57 PM Woody Gilk wrote:
On Mon, Nov 26, 2018 at 6:56 AM Marcos Passos
wrote:
Think about a loader interface, that can throw a LoadingException. A
StringLoader will never throw an exception, and any class tightly coupled to it
should not care about LoadingException.

In what situation would you have code tightly coupled to the implementation
instead of the interface?

--
Woody Gilk
https://shadowhand.me

--
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/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%40mail.gmail.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/CAAwdEzDXSt7DxNJYDzmA8bTv5nnxxL2jmdOHR2pdXUj2qSbiow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Alexandru Pătrănescu

A RemoteStringLoader implementation that will fetch the string from a
remote location and then use StringLoader by composition.

Alex

On Mon, Nov 26, 2018 at 3:57 PM Woody Gilk  wrote:

> On Mon, Nov 26, 2018 at 6:56 AM Marcos Passos 
> wrote:
>
>> Think about a loader interface, that can throw a LoadingException. A
>> StringLoader will never throw an exception, and any class tightly coupled
>> to it should not care about LoadingException.
>>
>
> In what situation would you have code tightly coupled to the
> implementation instead of the interface?
>
> --
> Woody Gilk
> https://shadowhand.me
>
> --
> 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/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%40mail.gmail.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/CAAwdEzDXSt7DxNJYDzmA8bTv5nnxxL2jmdOHR2pdXUj2qSbiow%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Woody Gilk

On Mon, Nov 26, 2018 at 6:56 AM Marcos Passos 
wrote:

> Think about a loader interface, that can throw a LoadingException. A
> StringLoader will never throw an exception, and any class tightly coupled
> to it should not care about LoadingException.
>

In what situation would you have code tightly coupled to the implementation
instead of the interface?

--
Woody Gilk
https://shadowhand.me

-- 
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/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Marcos Passos

I'm with Magna on this.

There are some classes that to do not thrown exceptions by design. Think
about a loader interface, that can throw a LoadingException. A StringLoader
will never throw an exception, and any class tightly coupled to it should
not care about LoadingException. It's an explicit design decision.

- Marcos

Em seg, 26 de nov de 2018 às 10:13, Alexandru Pătrănescu 
escreveu:

> Hi,
>
> I think it's a valid point of view.
>
> Simple example I can think of is that develop might want to use reuse the
> simple implementation that never fails instead of the interface in a
> private method/class.
> And he knows that it will not fail so it should not be hinted by editor to
> handle the exception.
>
> Alex
>
> On Mon, Nov 26, 2018 at 1:51 PM Robbie Averill 
> wrote:
>
>> Good afternoon,
>>
>> It seems to me that your interface says that it throws an exception "if
>> an operation fails." If your implementation has no way of failing, then the
>> fact that it never throws an exception is not of consequence. In future
>> your implementation may change and may fail, in which case you have an
>> exception you can throw without breaking the public API definition.
>>
>> TL;DR: I don't see a problem with your example code.
>>
>> Regards
>> Robbie
>>
>> On Mon, 26 Nov 2018 at 12:42, Nicholas Ruunu  wrote:
>>
>>> A lot of people, me included, try not to handle exceptions at all.
>>> But if you need to handle them, it's probably a good idea to do so even
>>> if the specific implementation doesn't throw.
>>> Since otherwise you'd have a problem if you switch to an implementation
>>> that do throw in the future.
>>>
>>> Den måndag 26 november 2018 kl. 12:28:06 UTC+1 skrev Magnar Ovedal
>>> Myrtveit:

 According to the current version of PSR-19, PHPDoc is implicitly
 inherited, and even when PHPDoc is present in both the subclass and the
 superclass, tags that are present in the superclass' PHPDoc but not in the
 subclass' PHPDoc are inherited.

 I think this is a very good idea, but I see a potential issue. Consider
 the following code.
 interface FooInterface {
 /**
 * @throws RuntimeException If the operation fails.
 */
 public function foo();
 }

 class FooImplementation implements FooInterface {
 public function foo() {
 // Do something that will never fail.
 }
 }

 FooImplementation::foo() will never throw an exception, but
 FooInterface allows other implementations of FooInterface::foo() to throw
 exceptions. For someone depending on FooInterface, they will have to handle
 any thrown exceptions. For someone depending on FooImplementation, however,
 they do not have to care about FooImplementation::foo() throwing
 exceptions. But there seems to be no way to prevent
 FooImplementation::foo() from inheriting the @throws tag from
 FooInterface::foo().

 Do we need a way to specify tags that should not be inherited?

>>> --
>>> 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/b1619215-f3e3-4865-9465-c5f2346a9536%40googlegroups.com
>>> 
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>
>> --
>> Robbie Averill | Senior Developer
>> 04 978 7330
>> http://silverstripe.com/
>>
>> --
>> 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/CANv6TC0PVd0enH6Euey11pd0%2BhGo7m4AkueN5CTVM_gJaoXvCg%40mail.gmail.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/CAAwdEzDjkq6_YgTVSGGQnNVi0a%2BsmLWVp9NC1OYPaejjW%2BKhZQ%40mail.gmail.com
>

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Alexandru Pătrănescu

Hi,

I think it's a valid point of view.

Simple example I can think of is that develop might want to use reuse the
simple implementation that never fails instead of the interface in a
private method/class.
And he knows that it will not fail so it should not be hinted by editor to
handle the exception.

Alex

On Mon, Nov 26, 2018 at 1:51 PM Robbie Averill 
wrote:

> Good afternoon,
>
> It seems to me that your interface says that it throws an exception "if an
> operation fails." If your implementation has no way of failing, then the
> fact that it never throws an exception is not of consequence. In future
> your implementation may change and may fail, in which case you have an
> exception you can throw without breaking the public API definition.
>
> TL;DR: I don't see a problem with your example code.
>
> Regards
> Robbie
>
> On Mon, 26 Nov 2018 at 12:42, Nicholas Ruunu  wrote:
>
>> A lot of people, me included, try not to handle exceptions at all.
>> But if you need to handle them, it's probably a good idea to do so even
>> if the specific implementation doesn't throw.
>> Since otherwise you'd have a problem if you switch to an implementation
>> that do throw in the future.
>>
>> Den måndag 26 november 2018 kl. 12:28:06 UTC+1 skrev Magnar Ovedal
>> Myrtveit:
>>>
>>> According to the current version of PSR-19, PHPDoc is implicitly
>>> inherited, and even when PHPDoc is present in both the subclass and the
>>> superclass, tags that are present in the superclass' PHPDoc but not in the
>>> subclass' PHPDoc are inherited.
>>>
>>> I think this is a very good idea, but I see a potential issue. Consider
>>> the following code.
>>> interface FooInterface {
>>> /**
>>> * @throws RuntimeException If the operation fails.
>>> */
>>> public function foo();
>>> }
>>>
>>> class FooImplementation implements FooInterface {
>>> public function foo() {
>>> // Do something that will never fail.
>>> }
>>> }
>>>
>>> FooImplementation::foo() will never throw an exception, but FooInterface
>>> allows other implementations of FooInterface::foo() to throw exceptions.
>>> For someone depending on FooInterface, they will have to handle any thrown
>>> exceptions. For someone depending on FooImplementation, however, they do
>>> not have to care about FooImplementation::foo() throwing exceptions. But
>>> there seems to be no way to prevent FooImplementation::foo() from
>>> inheriting the @throws tag from FooInterface::foo().
>>>
>>> Do we need a way to specify tags that should not be inherited?
>>>
>> --
>> 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/b1619215-f3e3-4865-9465-c5f2346a9536%40googlegroups.com
>> 
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
> --
> Robbie Averill | Senior Developer
> 04 978 7330
> http://silverstripe.com/
>
> --
> 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/CANv6TC0PVd0enH6Euey11pd0%2BhGo7m4AkueN5CTVM_gJaoXvCg%40mail.gmail.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/CAAwdEzDjkq6_YgTVSGGQnNVi0a%2BsmLWVp9NC1OYPaejjW%2BKhZQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Robbie Averill

Good afternoon,

It seems to me that your interface says that it throws an exception "if an
operation fails." If your implementation has no way of failing, then the
fact that it never throws an exception is not of consequence. In future
your implementation may change and may fail, in which case you have an
exception you can throw without breaking the public API definition.

TL;DR: I don't see a problem with your example code.

Regards
Robbie

On Mon, 26 Nov 2018 at 12:42, Nicholas Ruunu  wrote:

> A lot of people, me included, try not to handle exceptions at all.
> But if you need to handle them, it's probably a good idea to do so even if
> the specific implementation doesn't throw.
> Since otherwise you'd have a problem if you switch to an implementation
> that do throw in the future.
>
> Den måndag 26 november 2018 kl. 12:28:06 UTC+1 skrev Magnar Ovedal
> Myrtveit:
>>
>> According to the current version of PSR-19, PHPDoc is implicitly
>> inherited, and even when PHPDoc is present in both the subclass and the
>> superclass, tags that are present in the superclass' PHPDoc but not in the
>> subclass' PHPDoc are inherited.
>>
>> I think this is a very good idea, but I see a potential issue. Consider
>> the following code.
>> interface FooInterface {
>> /**
>> * @throws RuntimeException If the operation fails.
>> */
>> public function foo();
>> }
>>
>> class FooImplementation implements FooInterface {
>> public function foo() {
>> // Do something that will never fail.
>> }
>> }
>>
>> FooImplementation::foo() will never throw an exception, but FooInterface
>> allows other implementations of FooInterface::foo() to throw exceptions.
>> For someone depending on FooInterface, they will have to handle any thrown
>> exceptions. For someone depending on FooImplementation, however, they do
>> not have to care about FooImplementation::foo() throwing exceptions. But
>> there seems to be no way to prevent FooImplementation::foo() from
>> inheriting the @throws tag from FooInterface::foo().
>>
>> Do we need a way to specify tags that should not be inherited?
>>
> --
> 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/b1619215-f3e3-4865-9465-c5f2346a9536%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>


-- 
Robbie Averill | Senior Developer
04 978 7330
http://silverstripe.com/

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

PSR-19 Prevent PHPDoc inheritance

2018-11-26 Thread Magnar Ovedal Myrtveit

According to the current version of PSR-19, PHPDoc is implicitly inherited, 
and even when PHPDoc is present in both the subclass and the superclass, 
tags that are present in the superclass' PHPDoc but not in the subclass' 
PHPDoc are inherited.

I think this is a very good idea, but I see a potential issue. Consider the 
following code.
interface FooInterface {
/**
* @throws RuntimeException If the operation fails.
*/
public function foo();
}

class FooImplementation implements FooInterface {
public function foo() {
// Do something that will never fail.
}
}

FooImplementation::foo() will never throw an exception, but FooInterface 
allows other implementations of FooInterface::foo() to throw exceptions. 
For someone depending on FooInterface, they will have to handle any thrown 
exceptions. For someone depending on FooImplementation, however, they do 
not have to care about FooImplementation::foo() throwing exceptions. But 
there seems to be no way to prevent FooImplementation::foo() from 
inheriting the @throws tag from FooInterface::foo().

Do we need a way to specify tags that should not be inherited?

-- 
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/95e9ee2b-7e5a-4d05-890b-00229ba0098b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

PSR-19 @triggers tag

2018-11-26 Thread Magnar Ovedal Myrtveit

Would it be interesting to include a @triggers tag in PSR-19? This would be 
used with code that may call trigger_error() or other code that may trigger 
errors, such as filesize(), mime_content_type(), filemtime(), md5_file(), 
pspell_new(), etc. (There are really many!)

Examples would be:

@triggers E_ERROR Some text explaining what might trigger the error.

@triggers E_WARNING Some text explaining what might trigger the warning.

-- 
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/a044b2ab-a22a-4385-9a26-95c2fc1ac121%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Symfony leaving PHP-FIG

Re: Symfony leaving PHP-FIG

Symfony leaving PHP-FIG

Re: PSR-19 Prevent PHPDoc inheritance

Re: PSR-19 Prevent PHPDoc inheritance

Re: PSR-19 Prevent PHPDoc inheritance

Re: PSR-19 Prevent PHPDoc inheritance

Re: PSR-19 Prevent PHPDoc inheritance

Re: PSR-19 Prevent PHPDoc inheritance

PSR-19 Prevent PHPDoc inheritance

PSR-19 @triggers tag

11 matches

Site Navigation

Mail list logo

Footer information