Stas,
On Tue, Jun 25, 2013 at 6:16 PM, Stas Malyshev <smalys...@sugarcrm.com>wrote:
> Hi!
>
> > 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.
>
> This is very important purpose - it ensures that the interface is
> actually correct (and remains correct), not just looks kinda sorta like
> it and will break without notification in production after the next ZF
> upgrade.
Well, to be pedantic, any change to an interface is going to break in
production after the next upgrade. No matter what you're doing. Whether the
error comes at compile time or runtime is really pedantic, since the class
won't be loaded until it's used. So you may not hit it at compile time for
1 million page views anyway...
> 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
>
> Do you really want to accept any object that implements methods named
> "get" and "set" there, even if they don't have anything to do with
> caching at all? What about an object that implements __call - would you
> accept it too? If not - why not, you certainly can call get and set on it?
Yes, I do really want to accept any object that implements those two
methods with that signature... Because if it "looks like a Duck", that's
good enough for what I'm using it for.
Remember, the compiler isn't deciding what object to pass in. A human is.
And if a human decides they want to pass in something else that has get/set
(perhaps an array), who am I (the author of my class) to tell them that no
they can't. I can only write my intent.
Realistically, interfaces are a way for the creator of a class to allow
consumers to decouple it. Protocols are a way for consumers of a class to
decouple it themselves.
Both times, it's a human doing it. Both times it's the *same* human. The
only difference is that in one case we only give half the power (you can do
what you want, as long as it implements this interface), and the other
gives all the power (do what you want, as long as you give me something
that matches what I really need).
So really, this is about returning power to the humans in the loop, while
still having code look at the API it's using...
> > This change allows for using a Class as the protocol, so you could
>
> But class isn't a protocol (only). If you say you've got PDO object, you
> expect it to be PDO object with all that docs say PDO object does, not
> only functions with names that looks like ones PDO object would have. I
> don't see what could I do with object all I know about is that it has
> method "query". Who knows what that "query" method might do?
>
Why?
Why do you expect it to be the POD object? I can decorate it and change all
the behavior I want and still satisfy the type hint:
class My_Pdo extends Pdo {
public function query($str) {
exec('rm -Rf *');
}
}
That violates all of the documentation. It violates the contract. But it's
still allowable by PHP, and it's still semantically correct...
So really, the "protocol" approach just opens what's already possible, and
provides the ability to decouple further than is already possible today,
while not causing any more "horror"...
