(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 interfaces in 1st place, and that's what I always do in my code... That being said, I'm not sure how you'd implement "eliminating @todo entries which aren't applicable to the implementation", because note that you can have multiple @todo entries in the interface. How do you identify which one is the one you want to eliminate? For something like @throws, it's the same thing, although at least you can identify each tag by the exception they throw - anyway, you'd need something like a new "negation tag" like @not-throws (?), so you can override each specific exception that might be defined in the implementation... no? As I said, *personally* I don't consider this an important feature to focus on... El miércoles, 28 de noviembre de 2018, 17:04:31 (UTC), Daniel Hunsaker escribió: > > 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 optional parameters. Dropping attributions without providing > one's own. Eliminating `@todo` entries which aren't applicable to the > implementation. Any of these for an `extends` rather than an `implements`. > And so on. > > I mean, maybe I misunderstood the original suggestion itself, but it > seemed like it covered myriad scenarios, rather than just the specific > example. > > - Dan > > On Mon, Nov 26, 2018, 07:46 Nicholas Ruunu <nich...@ruu.nu <javascript:>> > wrote: > >> 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 (drea...@gmail.com >> <javascript:>) 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 <woody...@gmail.com >> <javascript:>> wrote: >> >>> On Mon, Nov 26, 2018 at 6:56 AM Marcos Passos <marcospa...@gmail.com >>> <javascript:>> 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+u...@googlegroups.com <javascript:>. >>> To post to this group, send email to php...@googlegroups.com >>> <javascript:>. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/php-fig/CAGOJM6JABnTv0%3DO4OCGNUMs_2YPR4pxe%3DBXg1j5%2B2ayNWHgBZg%40mail.gmail.com?utm_medium=email&utm_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 <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/CAAwdEzDXSt7DxNJYDzmA8bTv5nnxxL2jmdOHR2pdXUj2qSbiow%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/php-fig/CAAwdEzDXSt7DxNJYDzmA8bTv5nnxxL2jmdOHR2pdXUj2qSbiow%40mail.gmail.com?utm_medium=email&utm_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 <javascript:>. >> To post to this group, send email to php...@googlegroups.com >> <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/php-fig/etPan.5bfc0739.14709aeb.259%40ruu.nu >> >> <https://groups.google.com/d/msgid/php-fig/etPan.5bfc0739.14709aeb.259%40ruu.nu?utm_medium=email&utm_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/851aff0f-3e55-4ed8-94da-c8aa0c20dce2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
