IMO GO like interfaces become handy in the following situation: Library A wants that you pass a class at some point (let's say a logger) which implements interface ALogger (as defined by lib A) Library B wants that you pass a class at some point which implements interface BLogger
Both interfaces are identical (at the moment). There is no need to write an adaptor for one of those libraries if GO like interfaces are used. That's one use case for GO like interfaces (which of course could also be misused) @Anthony You also outline that protocols can be used for classes which make classes somewhat like interfaces. I do not like this idea and I am not familiar with GO but I doubt they use it like this. That really counteracts the principle that you should implement against an interface/abstraction. -----Ursprüngliche Nachricht----- Von: Stas Malyshev [mailto:smalys...@sugarcrm.com] Gesendet: Mittwoch, 26. Juni 2013 01:16 An: Anthony Ferrara Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] RFC: Protocol Type Hinting Hi! > So nobody should ever use libraries, because they can't be sure of > that code... So... Libraries have classes and interfaces for exactly this reason - so you can be reasonably sure what's in them or at least have easy way to check it. > It's checking that fatal method-not-defined erros won't be thrown... But instead a fatal "protocol does not match" error will be thrown. The difference? > It gives the ability for a method to be defensive by preventing > E_FATAL errors. That's not adding something significant? I fail to see the difference between one error and another error. The whole "catchable" thing is very artificial difference and as far as I'm concerned, if that's the problem, just make method-not-defined "catchable", whatever that might mean - there's no difference on the substance that I can see. > I agree the use-cases are slightly weak. This is a draft RFC. It's > supposed to help identify the areas where we can improve it. Help > identify use-cases. Help dig it out. My personal opinion regarding design always was that use cases come first. If I don't have a use case, there's nothing to design. So I'd like to see the convincing use case first. Then, once it's convincing, we can talk about implementation details - so yes, you can discard all the performance, etc. talk - it's not important right now, the most important thing is the use cases. -- 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
