wow... why did this just become a measuring contest. Do we need to go recruit people interested and attach their resume's?
I'll just toss in I am interested in this. Comparing to current methods of doing this sort of things(because if you're denying it exists in the wild, lets open up some of your code and be honest) I think the error is more useful then throwing an exception of causing a fatal error. 1. The error clearly specifies what is missing. It also leads to documentation in the form of the structured interface where you can understand why it failed and what the expectations are. 2. The error happens at the start of the call not in embedded in the code, possibly hidden from common runtime by conditions. This seems like a more ideal fail early sort of situation. I also think this is a cool thing we'll see someday useful in project integration. Say I'm building on top of a framework or library and want to use an implementation but want to treat it more like an interface and provide additional implementations. Not a stretch. My options are, don't type, hack this 3rd party tool, wait for another release where they might have addressed my concern. Instead I could provide this sort of interface and provide additional implementations of the interface and call it a day. If someday they add an interface its not a big change to take advantage of it and its forwards compatible if the interface matches the structured interface. So real work example out of the way, can we look at technical concerns? On Thu, Jun 27, 2013 at 10:08 AM, Laruence <larue...@php.net> wrote: > On Thu, Jun 27, 2013 at 10:54 PM, Laruence <larue...@php.net> wrote: > > On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara <ircmax...@gmail.com> > wrote: > >> 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 ;-)... > >> > >> 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... > > what's going on here? > > > > Stas has been a core contributor for a long time, if he didn't meet > > such usage, then I think 80%(or more) people doesn't have this need > > either. > > > > to be honest, I don't think this is useful either... (in case you > > will doubt my qualification, let me introduce myself a little more, I > > am a 6 years PHP, 5 year C engineer, develped a lots of PHP > > applications, and also some big scalar ones, like weibo.com which I am > > maintaining now, thanks) > > > > interface is enough, interface is exactlly doing the protocol control > > thing, and I think it does very well. and it also very strict and > > reliable. > > > > so, why we need such feature that only a few people need it( if there > > really is some). > > I missed one thing here, it should be: > why we need such feature that only a few people need it, and will > also make reset people confused, and most of other language doesn't > have it, and using it will make things a little mess(and low > performance vs pure interface)? > > thanks > > > > and about the performance, runtime check on every methods's signature > > in runtime, how could it be faster than current way? > > > > if you bring 1% slowdown in one feature, yes, it's trivail, but if > > you bring such features 100 times? > > > > and, I have to clarifiy, the main reason I don't like this proposal is > > usage, not the performance.. > > > > and last, I am poor at english, so I usually don't like to argue. > > sorry if I didn't make myself clear. > > > > thanks > >> > >> 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)... > > > > > > > > -- > > Laruence Xinchen Hui > > http://www.laruence.com/ > > > > -- > Laruence Xinchen Hui > http://www.laruence.com/ > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
