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. > 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? > 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? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
