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
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
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.
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
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
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
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
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
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
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
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:
11 matches
Mail list logo
