Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:67958 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71785 invoked from network); 27 Jun 2013 15:08:51 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 27 Jun 2013 15:08:51 -0000 Authentication-Results: pb1.pair.com smtp.mail=laruence@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=laruence@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.41 as permitted sender) X-PHP-List-Original-Sender: laruence@gmail.com X-Host-Fingerprint: 209.85.215.41 mail-la0-f41.google.com Received: from [209.85.215.41] ([209.85.215.41:54931] helo=mail-la0-f41.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 45/C7-34034-1855CC15 for ; Thu, 27 Jun 2013 11:08:49 -0400 Received: by mail-la0-f41.google.com with SMTP id fn20so968419lab.14 for ; Thu, 27 Jun 2013 08:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=9apFd+TIeRRttfK0g8IW8pEdh7rmNObPvaJkfzNzSqw=; b=YE6HX5/RqYdM5lvJmCN2TvNLrujpIEaduCFy6dULf7uoSIm1UzDMAgIe3xFXYiDUOP OoypoR2mBGPd9J5xX8jDGdmt33KKdSS0v256zr+vC8Ot/v5aN0bX96UFPjp3nFJZbeT/ 08ukfBeuSlTcKXks0f6T6fSgjVz15e8yxEV3HvRjcazyT8Gb5nVjJIjmm+ojzy71qGc0 ps5/BIK9BTaPhJo4Q6cYSIF20tutbl+EcOPbG69ksieUEs13Cmp2QpgPLHIIooQtDyaR c9ZAjMy97ovKKulCUWxZFi99fTgsv/rWywJ+5qrxu+KXMYpZWoHV3OdV6akvVbMzu8hc pZmQ== X-Received: by 10.152.9.69 with SMTP id x5mr4379385laa.57.1372345726217; Thu, 27 Jun 2013 08:08:46 -0700 (PDT) MIME-Version: 1.0 Sender: laruence@gmail.com Received: by 10.114.29.36 with HTTP; Thu, 27 Jun 2013 08:08:26 -0700 (PDT) In-Reply-To: References: <51C9FA9C.8050403@sugarcrm.com> <51CA1C93.6080500@sugarcrm.com> <51CA24C5.9090505@sugarcrm.com> <51CB167A.4020207@sugarcrm.com> Date: Thu, 27 Jun 2013 23:08:26 +0800 X-Google-Sender-Auth: Cs8EGMD7Fm6t1KK3gKw60kV2VCM Message-ID: To: Anthony Ferrara Cc: Stas Malyshev , "internals@lists.php.net" Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] RFC: Protocol Type Hinting From: laruence@php.net (Laruence) On Thu, Jun 27, 2013 at 10:54 PM, Laruence wrote: > On Thu, Jun 27, 2013 at 10:35 PM, Anthony Ferrara 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/