I had a quick look at GO and as far as I understand they do not use duck typing but a structural type system. http://golang.org/doc/faq#implements_interface
Please change this in your RFC to avoid misunderstandings. -----Ursprüngliche Nachricht----- Von: Anthony Ferrara [mailto:ircmax...@gmail.com] Gesendet: Mittwoch, 26. Juni 2013 16:29 An: Stas Malyshev Cc: internals@lists.php.net Betreff: Re: [PHP-DEV] RFC: Protocol Type Hinting Stas and all, But instead a fatal "protocol does not match" error will be thrown. The > difference? A recoverable protocol does not match error. And the difference is that the check is pushed to the caller as opposed to within the function. > > 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 think we should. And I think we should turn all non-engine related fatals into exceptions. But both are beyond the scope of this proposal... > 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. The use-cases did come first. Unfortunately they are not trivial to type out, and they are not trivial to really understand without actually playing with code. Which is one reason for this draft proposal... So that people can actually download the code and try it out. So that new use-cases beyond my own could be fit. So that people could try it out and comment and evolve the concept. As far as "discard all the performance, etc talk", it was Laruence and yourself that brought that up here. And it's something that a lot of people have jumped on. I find it funny that I have proven at least 3 times in this thread that performance is equal to or faster than the current interface approach, yet it still keeps getting brought up... Funny how arguments that support a stance are thrown around, even when they are disproven (and then they are at best ignored)... Additionally, I'd like to make a note here. There's been a lot of talk about "best practice" in this thread. I think that's exactly the wrong way that language features should be judged. What's currently accepted as "best practice" is subject to change over time. In practice it does. Just look at the past 5 years of development in frameworks. We went from completely Class-Oriented procedural codebases like Cake and ZF1 to completely OOP designed frameworks like Symfony and ZF2. What the "cool kids" in the community (the only way I can really describe the vocal minority of OSS contributors) consider "best practice" has changed Dramatically in the past 5 years. Hell, it's changed drastically in the past 5 months. Internals should not be taking sides on what's good practice and what's bad practice (if it was, why the heck was goto introduced?). Instead, it should enable today's good practice to be followed. But it should not take a stand about bad practice. It's a slippery slope to make the "best practice" stand. For example, one could make the argument that ignoring errors is not best practice, so therefore every non-truely-fatal error thrown by PHP should be an exception, to force the user to not ignore it. Reasonable? I don't know. But if you want to go down the "we need to follow best practice" route, that's the logical conclusion... My point here is that we should be judging features by their merit alone, and not by how we would use them. We also should not be judging them based upon our preferred style, but on the overall case of what it aims to achieve. Bringing this back on point, Duck-typing is a very valid and accepted way of doing OOP. In fact most other dynamic languages use this as the basis for their OOP system. This proposal does nothing but attempt to allow a little more safety and self-documentation to a use-case that today is pretty free-for-all... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
