On Wed, Jan 5, 2022 at 11:05 PM Larry Garfield <la...@garfieldtech.com>
wrote:
> On Wed, Jan 5, 2022, at 2:35 PM, Chase Peeler wrote:
>
> For point 2, that's mainly useful as a way to signal to other developers
> "hey, this trait has all but one method of the LoggerInterface, that's how
> you'd use it", and to signal static analyzers and refactoring tools the
> same thing so that they can be auto-updated if you tweak the interface. I
> can see a use for point 2, and it would make my life a bit easier, but it's
> overall not high priority.
>
>
I think existing constructs provide 99% of this benefit anyway.
interface I { public function hello(); }
abstract class A implements I { abstract public function hello(); }
trait T { public function hello() { echo 'hello'; } }
class C extends A { use T; }
// or alternatively
class D implements I { use T; }
// or
abstract class E implements I { use T; }
class F extends E { ... }
$c = new C;
$c->hello(); // $c is instanceof I
$d = new D;
$d->hello(); // $d is instanceof I
$f = new F;
$f->hello(); // $f is instanceof I
It's not quite as neat as directly having a way of annotating T to say it
implements I, but it does the job insofar as your IDE and tools should be
able to immediately pick up a change in interface I is not fulfilled by
anything relying on trait T to be of type I, either directly or by
inheritance.
The remaining 1% of benefit could probably be achieved just by naming
convention:
interface LoggerInterface { ... }
trait LoggerInterface_FileLogger { ... }
But I still think both goals would be better achieved with something like:
interface LoggerInterface {
default public function error(string $message) {
$this->logger->log('error', $message);
}
}
in the manner of Java...no idea how easy or not it would be for someone a
little more experienced than me working on PHP core to do this though.
- David
> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>
>
