Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:58371 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 22993 invoked from network); 29 Feb 2012 23:57:00 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 29 Feb 2012 23:57:00 -0000 Authentication-Results: pb1.pair.com header.from=simonsimcity@googlemail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=simonsimcity@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.214.170 as permitted sender) X-PHP-List-Original-Sender: simonsimcity@googlemail.com X-Host-Fingerprint: 209.85.214.170 mail-tul01m020-f170.google.com Received: from [209.85.214.170] ([209.85.214.170:47748] helo=mail-tul01m020-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 8D/AF-46815-C4BBE4F4 for ; Wed, 29 Feb 2012 18:57:00 -0500 Received: by obbwd1 with SMTP id wd1so12121obb.29 for ; Wed, 29 Feb 2012 15:56:57 -0800 (PST) Received-SPF: pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.36.106 as permitted sender) client-ip=10.182.36.106; Authentication-Results: mr.google.com; spf=pass (google.com: domain of simonsimcity@googlemail.com designates 10.182.36.106 as permitted sender) smtp.mail=simonsimcity@googlemail.com; dkim=pass header.i=simonsimcity@googlemail.com Received: from mr.google.com ([10.182.36.106]) by 10.182.36.106 with SMTP id p10mr982205obj.55.1330559817920 (num_hops = 1); Wed, 29 Feb 2012 15:56:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=pakqpwz1TAa7Dn6gX8UoAgwbHemjRM7lfkFkugkvZQw=; b=RDm5hJLIeG07u5s9cCwJvr4fBacfiJS38cGYyUTJAZ00SQ4Gi8Z0K9CDZmHgiL270D 3/FDl1OpvvX5tOxh6z8NZ0Gbo0cMt6xPd2Kl6HhHEhqq130cYGVrtiXUWBuGDH93FCgK LJCG0u1h/QIXNmcrvrTER0K7/YFbgj1VddVtk= MIME-Version: 1.0 Received: by 10.182.36.106 with SMTP id p10mr842434obj.55.1330559817801; Wed, 29 Feb 2012 15:56:57 -0800 (PST) Received: by 10.60.7.229 with HTTP; Wed, 29 Feb 2012 15:56:57 -0800 (PST) In-Reply-To: References: <1330357150.2159.30.camel@guybrush> <693e15008681dfe7372eaea66214f8a8.squirrel@www.l-i-e.com> <887FE7CFF6F8DE4BB3A9535F53AFD06AC3152C6C@il-ex2.zend.net> <887FE7CFF6F8DE4BB3A9535F53AFD06AC3152F5D@il-ex2.zend.net> <43409D28-75AC-4E9C-A0EA-66FC1DB9FAE7@gmail.com> Date: Thu, 1 Mar 2012 00:56:57 +0100 Message-ID: To: Kris Craig Cc: Matt Wilson , PHP internals Content-Type: multipart/alternative; boundary=f46d04447eeb4ae0ac04ba231967 Subject: Re: [PHP-DEV] Scalar type hinting From: simonsimcity@googlemail.com (Simon Schick) --f46d04447eeb4ae0ac04ba231967 Content-Type: text/plain; charset=UTF-8 Hi, All Sorry for pulling the old RFCs out. But why is their status is still *in draft* or something like that? I did not know something about the 6-month-rule. That's also what I mentioned before with the missing solution ... If you close an RFC or set it to *accepted*, please also write what has been accepted. Btw: the old RFCs need to be cleaned up some when ... archived ... As I see from your mails, you're not in detail following this conversation. Btw. The conversation got quite down to a personal level in the last hours ... not really talking about facts and arguments. I don't want a strict/weak type-binding of variables, either do I want something strict if you pass stuff into a function. I simply want to define a type for each argument of a function/method. If someone calls this function with a parameter that is not compatible with the required type, let it break. The other RFCs were just something I saw on my way. That's nothing I personally wanted to push forward (not right now at least) but they fit in our discussion and were written in an RFC that was related to what I wanted. @Kris: > I prefer the latter, which is why I am now pushing this. What I am very thankful for ;) Bye Simon 2012/2/29 Kris Craig > With all due respect, it's a logical fallacy to draw a direct comparison > between these two simply because they both happen to be uphill battles. > > We've demonstrated in this discussion that it can, in fact, be done without > breaking the PHP concept at all. The only consistent argument I'm hearing > against it is, "It's been voted down before." And yet, it keeps coming > up. Why do you suppose that is? Mind you, this is the first time that I > have ever brought this up. So it's not just me. Ignoring this obviously > hasn't made it go away. We can either continue sitting in denial and > whining whenever somebody brings this up, or we can finally stop > procrastinating and take on the unpleasant task of actually working this > out. PHP 6 presents the perfect opportunity for something like this > anyway. > > > Voting it down hasn't made it go away. What is it they say about the > definition of insanity? Doing the same thing over and over again and > expecting a different result. This concept has been proposed in many > different ways, but now it seems like some of you have decided to just vote > it down because you're tired of it being talked about. But that hasn't > worked, has it? And it won't. So we can either keep doing this every 6 > months or we can try to work something out that addresses this finally. > Even if we were to take the totalitarian approach of restricting the voting > process, that wouldn't stop people from bringing this up on the list, so > the "problem" of people continuing to bring this up would still go on. > > Seriously, just step back and look at this from a practical, logical > standpoint. What we've been doing hasn't worked. Summarily voting > anything resembling this down to make it go away hasn't made it go away. > One of the main reasons I finally jumped into this discussion after all > these years is because I noticed this pattern was once again repeating > itself in the enum thread. This isn't going to just magically go away. > People aren't going to "see the light" and suddenly stop asking for this > just because they've realized the core devs decided to click the "ignore" > button. We can either keep repeating this pattern or we can step out of > denial and finally address this. I prefer the latter, which is why I am > now pushing this. > > --Kris > > > On Wed, Feb 29, 2012 at 2:46 PM, Matt Wilson wrote: > > > I once pushed this hard for namespaces. Then, after years of it being > shot > > down, they did it. > > > > And now I'm sad. It didn't occur to me until after it had been > implemented > > how bad an idea it was for php. I think this is one of those times. > > > > Type hinting is wonderful, but i'm not sure you could really make it fit > > in php without bastardizing the concept. > > > > The last time I looked at this discussion, I saw something about > call-time > > silent type conversion (essentially foo((int) $bar)) and if that's not > > bastardizing a concept... > > > > I think the community has spoken. And when the core devs put their foot > > down, I think it's best to listen. If it's so important to you, then by > all > > means, fork. Or simply write a patch. Put it to a vote. But this is > beating > > a very dead horse. > > > > -M > > > > On Feb 29, 2012, at 4:36 PM, Kris Craig wrote: > > > > > I agree. I'm against strict type hinting as well. Of course, nobody > > here > > > is suggesting that we should go with strict typing, so it's a moot > > question > > > anyway. > > > > > > --Kris > > > > > > > > > On Wed, Feb 29, 2012 at 2:35 PM, Arvids Godjuks < > > arvids.godjuks@gmail.com>wrote: > > > > > >> Please.read my emails carefuly. What i said is last time the work has > > been > > >> done, and two different patches have been developed and iterated. But > > >> dificulties in implementation and strong resistance from the devs and > > >> comunity got it killed. I actually had a post on our biggest russian > > >> speaking IT resource and results shown that majority of comunity was > > >> against strict type hinting - it does not fit PHP philosophy. Simple > as > > >> that. > > >> Thats all, if you cant unders > > >> > > > > > --f46d04447eeb4ae0ac04ba231967--