Hi! > 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...
So, the question of what is the difference between the two errors remains unanswered. If the whole diff is that one of the errors has word "recoverable" in the message, it's not substantial difference at all and one that does not require new syntax and big change in the language. > 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 Can we please lay the goto argument to rest? The argument "goto was introduced, so feature X must too, because goto was introduced" didn't sound good even the first time... > should enable today's good practice to be followed. But it should not > take a stand about bad practice. In my opinion, we should. We should not take into the language any concept that anyone considers useful in some particular piece of code. PHP language is very widely used, and we should consider how it would influence this huge ecosystem and if the overall effect would be beneficial and justify complicating (if there is one) the whole language system. Language is a system of thought and a system of approaching communication. IMO, this means it should have some principles and not just be a random bag of things that somebody at one point or another decided to stick into it, they should make sense together. PHP doesn't have the best reputation in this regard, but we are trying to make it better, not worse. It does not mean we should avoid change. It means we should have good reasons for change and carefully consider it. Good use cases IMO are prerequisite for that. > 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. IMO there's no merit in the feature besides its use. That's the only merit a feature could or should ever have. > 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 In fact, most other dynamic languages don't even have parameter typing. Neither Perl, Python, Ruby or Javascript have it. Let alone typing of the kind you suggest. What they have we have too. Duck typing for them doesn't mean what you propose - it means what we already have, checking type at the point of use. Check https://en.wikipedia.org/wiki/Duck_typing and see the examples - most of them don't have any typechecks. Referring to "most dynamic languages" while promoting this proposal is a bit misleading. -- 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
