2013/6/27 Anthony Ferrara <ircmax...@gmail.com> > Stas et al, > > > 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. > > > I'm assuming that you do know the difference between E_RECOVERABLE_ERROR > and E_ERROR. And the difference is not trivial... > > > > > 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... > > > I'm absolutely not trying to say we should include this because GOTO was > introduced. I'm trying to point out the circular nature of the argument of > good-vs-bad practice in general... > > > > > 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. > > > Of course they are. Use-cases matter. A lot. > > But "good practice" vs "not-good-practice" shouldn't be a significant > factor, because your "good-practice" is different from mine. And unless we > as a group decide to stick to one interpretation (we haven't), then it's > kind of pointless to talk about good practice. If you want to vote based on > it, that's your prerogative. But in general I think that thought process is > dangerous for the community as a whole and for core... > > > > > 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. > > > Ok, so then you agree that "best-practice" doesn't come into it at all...? > > > > > 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. > > > > Those other languages (all of them in fact) throw exceptions if the > function or method does not exist. PHP hard fatals. They can live with pure > duck-typing because their engines are designed to stay running, where ours > is designed to fall on its face. This proposal is one attempt to bring some > consistency and recoverability to the dynamic aspect of programming while > providing for the ability to verify APIs at the engine level. > > One thing I find interesting is that I have discussed this feature with > about 50 people at this point (quite a few at conferences and such before > actually proposing it), and the sentiment elsewhere (not on list) was very > predominately "this solves a ton of problems". I find it interesting that > on-list people seem to think that I'm making the use-cases up, and that > there's not really a problem to solve. I wish some of the other people I > talked to would speak up here ;-)... >
You havent talked to me, but I bring my voice in. > > One thing to note is who the major audience for a feature like this is. > It's not predominately for 1st party developers (developers writing one-off > applications). It's not predominately for 2nd party developers (developers > writing frameworks and other applications that have few dependencies and > are intended to be used by 1st party developers). It is primarily for 3rd > party developers. These are developers that maintain code bases built on > top of 2nd party code, but meant to be used by 1st party developers. > > What does that mean? The average one-off application builder is likely to > not get much use out of this (it can be used, but the problems for this > group of people are mostly solved already). The average framework core-dev > (like Symfony or ZF) isn't going to get *much* benefit out of this either > (it can help in some areas, and they will use it, but it's not solving > major problems). The Drupals, Magentos and Fuel CMS's of the world. The > people who make plugins and modules for Frameworks and CMS's. > > Basically, the people who's lives will get MUCH easier with something like > this are the people who maintain code that has a lot of dependencies, and > that other people depend on (it sits in the middle of the dependency chain, > where code on both sides is outside of their control). > > So if you don't see the usefulness of this type of change, ask if you > maintain anything significant that fits that description. If you don't, > find someone who does and talk to them. Otherwise you may be unfairly > judging by ignoring problems that you personally don't have... > > Anthony > > PS: I updated the RFC with a number of use-cases, including the ability to > hint on Traits (more specifically, the API of a trait)... > -- github.com/KingCrunch
