I see your point, but maybe I didn't explain myself well enough. Take the example of an interface. Interfaces aren't directly accessible (callable), they don't have any functional code in them. So why have them? What is the single best advantage of an interface, especially in a very large organization? It ensures consistency.
Take PDO for instance. They are a perfect candidate for interfaces. The actual implementation of the close() method will differ based on the RDBMS, but functionally, to the end-developer, they are the same. It closes the database connection. Once a class implements an interface, and the end-developer knows this, they don't have to worry about the name of the method that closes the connection. Also, if the lead architect decides that there must be a method called foo() in each of the given libs, he/she needs only to enforce this through the interface, which is implemented by each class! This can also assist in debugging. I understand that there's a real difference between type-hinting return values and parameters, but reverting back to the interface practice, why not depend on the developer to add a new form of documentation to "promise" to implement certain methods? Will -----Original Message----- From: Stanislav Malyshev [mailto:[EMAIL PROTECTED] Sent: Sunday, July 29, 2007 3:07 AM To: Will Fitch Cc: 'Jeremy Privett'; 'Larry Garfield'; internals@lists.php.net Subject: Re: [PHP-DEV] Re: Type-hinted return values in PHP5? > On one hand I agree, since PHP is so loosely typed. But it's hard to make > the argument that type-hinting return values is pointless, since PHP allows > (class) type-hinting with parameter values. I personally think type-hinting > is very nice, and not for the purposes of IDEs. The difference is that typehinting works this way: 1. I'm a library, I want to get type X for $foo 2. I put typehint, so I didn't need to check if $foo is X 3. If you pass not X to $foo, my code is going to tell you that you can't do that And return type works like that: 1. I'm a library writer that says foo() returns X 2. I have to use for it, since I don't use foo() 3. You're client, so you read the docs and see foo() returns X 4. You write code which supposes foo() always returns X 5. I decide these return types are more trouble than they are worth, and make foo() return false on error, removing return type. 6. Your code has no way to check I did that, so it's broken now. Basically, it sums up to documentation - if documentation isn't right (or if it changed and you didn't follow) your code is going to break and you have no way to prevent it. That's what you have now with @return - why add language construct? > If one of the best selling points of PHP is its typeless environment, then > why make any of these available? It appears that we are moving more and If it was up to me, I'd probably not bother adding input typehints either :) But as I said above, input typehints are significantly different from return types. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
