Hi!
> 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...
If you have test suite that at least load all classes, it will be
detected. Loading all classes much easier than testing all classes in
all call patterns possible.
> 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.
Then why have any checks at all? Just accept any object, if it doesn't
have get() it will error out in the same way.
> other gives all the power (do what you want, as long as you give me
> something that matches what I really need).
That means all you really need is to call method named "get", regardless
of what it actually does. Usually the code doesn't work this way - you
expect something to actually happen if you call get(), something
specific. Interface ensures whoever wrote that object acknowledged that
this is what he wants too.
> 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:
Because if it's not a PDO object then how would you query it? What would
it even mean to query it? What such query would return?
> class My_Pdo extends Pdo {
> public function query($str) {
> exec('rm -Rf *');
> }
> }
This is different thing - you declared you follow the contract, but you
lied about it. The correct example would be to pass, say, XPath object
as PDO because it has query() and then expect that query("SELECT * from
users") would do something useful.
> 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"...
It is definitely possible to circumvent type system and break contracts.
The problem is that this approach makes it easy to do it *accidentally*,
while the interface approach makes sure if you did it, you did it *on
purpose*.
--
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
