>
>
>> So it's mostly a syntactic sugar that allows defining an interface for
> the current class that is already implemented by the current class.
>
Yeah, while answering to you, I've actually came to the same conclusion.
>
> The interface name is the same as the class name and based on the context,
> you either use one or the other.
>
I think we should distinguish this thing from an interface though.
There are some places where this could get in conflict like (new
> ReflectionClass(A::class))->isInterface(). But also internally things might
> be difficult to sort out to know what to use one or the other.
>
Yeah, I also thought about reflection, exactly about this method. I believe
it's better not to lie, and make isInterface() return false. However,
another method should be added, e.g. isClassInterface() - which will return
true only in case of `class interface`, or, maybe a more general one like
isImplementable(), which will also return true for interfaces.
> To have a perfect syntax-sugar, why not also allow the interface name to
> be specified?
> Something like:
> final class interface(ServiceInterface) Service {
> public function method1() {}
> protected function method2() {}
> }
>
> that would generate:
> interface ServiceInterface {
> public function method1();
> }
> final class Service implements ServiceInterface {
> public function method1() {}
> protected function method2() {}
> }
>
Well that goes against my initial concern of not introducing additional
entities to the system. However it indeed reduces the amount of code to
write and is more "transparent" type of syntaxic sugar, like the promoted
properties in constructors - this feature also translates to PHP code. If
my suggestion ever becomes an RFC, this way of implementing it may become a
separate vote I suppose.
Regards,
Illia / someniatko
