Re: PSR-19 Prevent PHPDoc inheritance

Sorry, wrong thread.Am 05.10.2019 11:03 schrieb Nils Rückmann :That's an issue, indeed. I've already thought about it and the only solution I can think of is to mark types explicitly (see jsdoc: `{int}`). This would also allow renderers and IDEs to link types even if they are part of the

Re: PSR-19 Prevent PHPDoc inheritance

That's an issue, indeed. I've already thought about it and the only solution I can think of is to mark types explicitly (see jsdoc: `{int}`). This would also allow renderers and IDEs to link types even if they are part of the description. But this is another topic.Am 05.10.2019 10:22 schrieb Ben

Re: PSR-19 Prevent PHPDoc inheritance

Hello, One solution here is to remove @throws from the list of tags that must be inherited. I guess the aim of having @throws inherited is like Java checked exceptions? Though, haven't other languages like C# avoided this because it creates just as many problems as it solves? On Monday,

Re: PSR-19 Prevent PHPDoc inheritance

phpstan-exception-rules has implemented support `@throws void` to disable inheritance of the `@throws` annotation: https://github.com/pepakriz/phpstan-exception-rules/commit/702688c127a8b86e4f9c19feae25dc86f6135ec6 On Thu, 6 Dec 2018 at 07:58, Magnar Ovedal Myrtveit wrote: > @Daniel Hunsaker

Re: PSR-19 Prevent PHPDoc inheritance

@Daniel Hunsaker Yes, the idea was a generic solution that would cover all tags, not just @throws. @Miguel Rosales Possibility to prevent inheritance of individual entries of a tag seems overkill to me, and it would lead to a major change in the PSR. Currently either all entries of a tag are

Re: PSR-19 Prevent PHPDoc inheritance

I'm -1 on this... it seems too edge casey to me to come up with a new complex way to handle it. CRB *about.me/ashnazg * On Wed, Nov 28, 2018 at 11:44 AM Miguel Rosales wrote: > (I think I've sent this message to 3 wrong places now - trying again... 臘) > > Personally, I

Re: PSR-19 Prevent PHPDoc inheritance

(I think I've sent this message to 3 wrong places now - trying again... 臘) Personally, I think that if a class is an implementation of an interface, their methods' docblocks should stick to the interface methods' docblocks as they are, because that fits better with the purpose behind using

Re: PSR-19 Prevent PHPDoc inheritance

Personally, I think that if a class is an implementation of an interface, their methods' docblocks should stick to the interface methods' docblocks as they are, because that fits better with the purpose behind using interfaces in 1st place, and that's what I always do in my code... That

Re: PSR-19 Prevent PHPDoc inheritance

Reading through this, I couldn't help but think the example was getting in the way of the suggestion, here. There are any number of tags, besides `@throws`, which could benefit from being removed from child implementations without outright replacing them, given the right use cases. Removal of

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 Prevent PHPDoc inheritance

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

Re: PSR-19 Prevent PHPDoc inheritance

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