>Среда, 5 января 2022, 4:17 +03:00 от Larry Garfield <la...@garfieldtech.com>:
> 
>On Tue, Jan 4, 2022, at 4:35 PM, Kirill Nesmeyanov wrote:
>> Hello internals!
>>
>> Since «traits» are often an indicator of not very good code and many
>> may not use them quite correctly, for example, as helpers, I suggest
>> adding support for the `expects` keyword to indicate that the trait is
>> part of the code decomposition taking into account ISP.
>>
>> For example:
>> ```
>> // Definition
>>
>> trait LoggerTrait expects LoggerInterface
>> {
>>     // ...
>> }
>>
>> // Usage
>>
>> class MyService
>> {
>>     use LoggerTrait; // Fatal Error: Class MyService
>> expects LoggerInterface to be implemented
>> }
>>
>> class MyService2 implements LoggerInterface
>> {
>>     use LoggerTrait; // OK
>> }
>> ```
>>
>> How relevant do you think this idea/proposal is? And what possible
>> problems or solutions will this entail in the future?
>I can't say this has ever been an issue for me when using traits. I've never 
>had a trait that needed to be used by a class with a given interface. What I 
>usually have is a trait that is a full or mostly implementation of an 
>interface. So this would be much more useful to me:
>
>trait LoggerTrait implements LoggerInterface { ... }
>
>(Perhaps some way to indicate that it mostly implements, and the rest are 
>abstract methods? Or require the other methods to be explicitly abstract?)
>
>I think it's subtly different, as it approaches the question from the other 
>direction.
>
>--Larry Garfield
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit:  https://www.php.net/unsub.php

I don't like this option, as now traits are a mechanism for injecting code into 
classes or other traits. However, they do not affect the type system in any way.

And if we add «trait implements», then each `use XxxTrait` will affect the type 
system.  That is, instead of changing the child type by explicitly specifying 
which interfaces it implements, the type will be modified taking into account 
the mechanism that did not change this type initially.
 
I don’t know, it’s just a feeling that this is not correct. And I have no other 
arguments against the concept of «`implementation Interface`». I need to think 
about it…
 
--
Kirill Nesmeyanov

 

Reply via email to