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
