I mean, converting class into interface or vice versa is regular operation
in my codebase, and it doesn't make huge diff: using of a contract is just
the same.
On Friday, December 6, 2019 at 2:27:35 AM UTC+3, Daniel Plainview wrote:
>
> > I saw this being said above by Daniel Plainview:
> > You would still break BC for anyone who instantiates the Logger class.
>
> True, but it breaks potentially less amount of code.
> For example, it's a common to use bundles that instantiate services. So
> these bundles may keep BC, but code which just uses Logger won't be
> affected at all.
> Invalid instantiation in many cases may be detected at compile-time
> (compilation of container), and it's way safer than runtime BC breaks.
>
> On Sunday, October 13, 2019 at 7:30:29 PM UTC+3, Andreas Hennings
> (donquixote) wrote:
>>
>> This is an interesting discussion.
>>
>> I could imagine an ideal world where "Response" is the interface name,
>> and "SimeKindOfResponse" is a specific implementation / class.
>> In such an utopia, if you see a "Response" as a parameter type hint, you
>> immediately know this is an interface.
>>
>> The world that I live in has a lot of legacy code where "Response" can
>> very well be a one-off class, and no interface is to be seen anywhere.
>> Even worse, the class might have a lot of public methods or even some
>> public properties (or anonymous properties) which are used by some consumer
>> code, but which we don't want to extract into an interface.
>>
>> In such a world, the suffix "Interface" offers a welcome distinction to
>> the one-off legacy classes.
>>
>>
>> I saw this being said above by Daniel Plainview:
>>
>> Ironically, I think this is disadvantage: you don't need to know about
>>> it.
>>> Further, if you don't allow inheritance like this: final class Logger,
>>> you would be allowed to convert Logger into an interface without breaking
>>> BC.
>>
>>
>> You would still break BC for anyone who instantiates the Logger class.
>>
>>
>>
>>
>>
>>
>> On Saturday, December 22, 2018 at 9:12:12 AM UTC+1, Dmitriy Zhirnov wrote:
>>>
>>> it's time to redesign Zend framework at all
>>>
>>> понедельник, 15 августа 2016 г., 23:02:46 UTC+3 пользователь Woody Gilk
>>> написал:
>>>>
>>>> How do you propose to resolve this common problem?
>>>>
>>>>
>>>> namespace Zend\Diactoros;
>>>>
>>>> use Psr\Http\Message\ServerRequestInterface;
>>>>
>>>> class ServerRequest implements ServerRequestInterface { ... }
>>>>
>>>>
>>>> When the class name is the same as the interface name, you have to use
>>>> aliases. The correct approach for the problem you put forward is:
>>>>
>>>>
>>>> use Psr\Http\Message\ServerRequestInterface as ServerRequest;
>>>> use Psr\Http\Message\ResponseInterface as Response;
>>>>
>>>> public function __invoke(ServerRequest $request, Response, callable
>>>> $next) { ... }
>>>>
>>>>
>>>> To wit, alias the interface in code that uses the interface if you find
>>>> it annoying.
>>>>
>>>> I am strongly AGAINST this change as it results in churn for an a huge
>>>> number of projects without adding any value.
>>>>
>>>> --
>>>> Woody Gilk
>>>> http://about.me/shadowhand
>>>>
>>>> On Mon, Aug 15, 2016 at 2:53 PM, Matthieu Napoli <matt...@mnapoli.fr>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> This is a 2 weeks discussion before going to a vote.
>>>>>
>>>>> The "Interface" suffix has been questioned a few times already, I'm
>>>>> suggesting we put that up to a vote and avoid future debates. Here are
>>>>> relevant threads I could find on the topic:
>>>>>
>>>>> - https://groups.google.com/d/topic/php-fig/Zgfd0gHUUoc/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/dPwtKqO3Zqk/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/10lM-UNudvU/discussion
>>>>> - https://groups.google.com/d/topic/php-fig/aBUPKfTwyHo/discussion
>>>>>
>>>>> Suggested change: *replace "MUST" to "MUST NOT" in "Interfaces MUST
>>>>> be suffixed by Interface"* from
>>>>> http://www.php-fig.org/bylaws/psr-naming-conventions/
>>>>>
>>>>> I do not suggest accepted PSRs are changed.
>>>>>
>>>>> Please share your reasons to vote FOR or AGAINST the change, let's
>>>>> debate for 2 weeks or more, and then let's have a vote to settle this.
>>>>>
>>>>> Discussion will last for at least 2 weeks (20:40 UTC on 29 August
>>>>> 2016).
>>>>>
>>>>> ---
>>>>>
>>>>> Here are my arguments to vote FOR the change:
>>>>>
>>>>> *- the Interface suffix makes simple names very long*
>>>>>
>>>>> For example with PSR-7, here is the signature of a Slim/Zend
>>>>> Expressive middleware:
>>>>>
>>>>> public function __invoke(ServerRequestInterface $request,
>>>>> ResponseInterface $response, callable $next) : ResponseInterface
>>>>>
>>>>> {
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> Compare that to:
>>>>>
>>>>> public function __invoke(ServerRequest $request, Response $response,
>>>>> callable $next) : Response
>>>>>
>>>>> {
>>>>>
>>>>> }
>>>>>
>>>>>
>>>>> The last one is much simpler and clearer. Typing and reading the first
>>>>> one is a huge pain. This point applies of course to all PSRs, not just
>>>>> PSR-7.
>>>>>
>>>>> *- the Interface suffix makes the interface a detail and the
>>>>> implementation the main thing, it should be the other way around*
>>>>>
>>>>> We should care about the interface, not the implementation.
>>>>> Type-hinting against LoggerInterface means that "Logger" (the
>>>>> implementation) is still "*the* logger", and the interface is a
>>>>> secondary concept that we explicitly inject for decoupling.
>>>>> If "Logger" was the interface, it would be even more obvious that the
>>>>> interface is the most important part. The implementation is secondary and
>>>>> I
>>>>> don't even care how it's named. I just want a logger and that's what the
>>>>> interface is.
>>>>>
>>>>> Regarding the inconsistency it would create between PSRs I think it's
>>>>> nothing compared to what we would gain in terms of developer experience.
>>>>>
>>>>> Matthieu
>>>>>
>>>>> --
>>>>> 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.
>>>>> To post to this group, send email to php...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.com
>>>>>
>>>>> <https://groups.google.com/d/msgid/php-fig/ea157c85-77b0-4fd4-a945-087ff1970a6c%40googlegroups.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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/9e0492d1-ef35-446d-a27f-015feee85476%40googlegroups.com.
