Hi,
On Tue, Jun 25, 2013 at 11:54 PM, Anthony Ferrara <ircmax...@gmail.com> wrote:
> Laruence,
>
> Hey:
>> Just one question, usage? why we need this? (run-time check is
>> slow and I can not think out of a case then we must need it)
>>
>
> 1. Library implementers don't need to declare a dependency for a third
> party library to use the interface from it.
>
> This may sound trivial, but imagine this. Right now Zend and Symfony have
> very similar providers for certain tasks. One of the ones that comes to
> mind (besides logging) is caching. If you want to use a Zend component in
> an Symfony app while still using caching today, you'd need to shim together
> an adapter to satisfy the zend cache interface with the symfony cache
> interface. Which means your project now depends on all three, as well as
> requiring the zend cache code for the sole purpose of loading the interface
> required by the component.
>
> That's loading a LOT of code that you don't need, just to avoid having to
> setup two caches...
>
> Instead, the zend component could depend on the narrow api that it needs.
> It only calls the ->get($key) and ->set($key, $value) methods, so create a
> (new?) interface with that limited API, and then type against it as a
> protocol. Now that interface still would need to be loaded, but the Symfony
> class can resolve that interface directly. Without the need to load
> anything from Zend cache (said caching interface doesn't need to be there)
> or wire anything else for you.
>
To me this seems like a pseudo-problem.
If Symfony and Zend would actually want to use components from each
other then they shouldn't try to avoid hinting at the corresponding
interface directly.
I would feel much better to know that my project takes 200 more KB of
data on the hard drive and the autoloader can automatically load the
interface from Zend when I'm in a Symfony2 project and I'm hinting
that interface.
And here's a problem that I could see of it: what happens when this code?
// Third party Mighty Logger Library
interface Logger {
public function log($argument);
}
// My beloved implementation
class Demo {
public function log($argument) {}
}
class UseMe {
public function shazam(<Logger> $logger) {
$logger->log('shazam');
}
}
$demo = new Demo();
$useMe = new UseMe();
$useMe->shazam($demo);
becomes
// Third party Mighty Logger Library
interface Logger {
public function log($argument);
public function unlog($argument);
}
// My beloved implementation
class Demo {
public function log($argument) {}
}
class UseMe {
public function shazam(<Logger> $logger) {
$logger->log('shazam');
}
// New method written by different enthusiastic programmer
public function kazam(<Logger> $logger) {
$logger->unlog('kazam');
}
}
$demo = new Demo();
$useMe = new UseMe();
$useMe->shazam($demo);
$useMe->kazam($demo);
>From code quality point of view, if I want to use methods from a
certain class / interface, I could always hint at that. And if you
look at my example, you clearly see that you should modify this as
it's right there, but when using a IoC at the object comes from
another place it might not be that easy to find out there Demo is and
implement new stuff out.
As for setting up a third library of common interfaces, maybe FIG
could solve that, if they ever pass the point when they create laws
about laws to govern them.
If I got this wrong then maybe you should consider improving your
examples because right now, from those examples alone it just looks
like a more problematic way of having a object hinted at.
Best regards
----
Florin Patan
https://github.com/dlsniper
http://www.linkedin.com/in/florinpatan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
