Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:37144 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 31198 invoked from network); 19 Apr 2008 08:24:05 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 19 Apr 2008 08:24:05 -0000 Authentication-Results: pb1.pair.com smtp.mail=markus@fischer.name; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=markus@fischer.name; sender-id=unknown Received-SPF: error (pb1.pair.com: domain fischer.name from 62.179.121.49 cause and error) X-PHP-List-Original-Sender: markus@fischer.name X-Host-Fingerprint: 62.179.121.49 viefep31-int.chello.at Solaris 10 (beta) Received: from [62.179.121.49] ([62.179.121.49:61373] helo=viefep31-int.chello.at) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/69-06290-32CA9084 for ; Sat, 19 Apr 2008 04:24:04 -0400 Received: from genuine.home ([84.112.136.139]) by viefep31-int.chello.at (InterMail vM.7.08.02.02 201-2186-121-104-20070414) with ESMTP id <20080419082359.UAAN20559.viefep31-int.chello.at@genuine.home>; Sat, 19 Apr 2008 10:23:59 +0200 Received: from ncvielp07.home ([192.168.1.51]) by genuine.home with esmtpa (Exim 4.50) id 1Jn8Ju-0003Vu-NJ; Sat, 19 Apr 2008 10:21:15 +0200 Message-ID: <4809AC21.5000205@fischer.name> Date: Sat, 19 Apr 2008 10:24:01 +0200 User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) MIME-Version: 1.0 To: Stanislav Malyshev CC: internals@lists.php.net References: <46ccd1ab0804170742g142ed562t4f03339da549a820@mail.gmail.com> <1208445852.5366.31.camel@felipe> <48079A46.9090403@zend.com> <1208458365.6148.21.camel@sbarrow-desktop> <48079F30.4090203@zend.com> In-Reply-To: <48079F30.4090203@zend.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=C2272BD0; url=http://markus.fischer.name/my_public_key.txt Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -45 X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "genuine.home", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Hi, [I'm replying also to Lukas email because of the similarity] Stanislav Malyshev wrote: >>> When you can use string but not object with __toString? >> >> my patch does that > > Ok, that's great. So then it makes sense to allow converting int->string > too, right? And then it'd also make sense to allow string->int too? > Especially if we have object->int convertor and that can be allowed too. > > In fact, we have good old conversion system used in parse_parameters. So > why not use the same rules? That'd make at least some sense - give PHP > programmers the tools that extension C programmers have. I still > wouldn't like it too much but at least it would make sense :) [...] Content analysis details: (-4.6 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -3.3 ALL_TRUSTED Did not pass through any untrusted hosts -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0042] 1.3 AWL AWL: From: address is in the auto white-list Subject: Re: [PHP-DEV] [RFC] Strict type hints (parameter and return value) From: markus@fischer.name (Markus Fischer) Hi, [I'm replying also to Lukas email because of the similarity] Stanislav Malyshev wrote: >>> When you can use string but not object with __toString? >> >> my patch does that > > Ok, that's great. So then it makes sense to allow converting int->string > too, right? And then it'd also make sense to allow string->int too? > Especially if we have object->int convertor and that can be allowed too. > > In fact, we have good old conversion system used in parse_parameters. So > why not use the same rules? That'd make at least some sense - give PHP > programmers the tools that extension C programmers have. I still > wouldn't like it too much but at least it would make sense :) What would happen to that *type* itself, would it be converted when it gets into the function, is that what you're proposing? ------------------------------ $i = 5; function foo(string $s) { // $s implicitely gets "5" ? } foo($i); ------------------------------ I may be missing something but in this context, "string" doesn't get very useful (I think), because besides arrays / objects (except __toString), everything can be converted to a string, it isn't "type hinting" anymore but "type converting". What about I/O parameters? ------------------------------ $i = 5; function foo(string &$s) { // $s implicitely gets "5" ? } foo($i); // $i is now "5" ? ------------------------------ I think that's a major "wtf" factor. I also think for many people, including me who favor strict types, also see it as a helpful protection mechanism. During development it happens regularly that I mix up parameters, but still my code continues execution. Sometimes this can be fatal, wrong variable wrong value wrong place and suddenly I've values at certain code points I wouldn't have expected them there. user id instead of a name there, etc. Or when somewhere an external input leaks down into the code with a wrong type/value because it isn't checked anyway, suddenly a catchable fatal error is thrown and the application is (can be ...) automatically protected by not further executing it. sincerely, - Markus