Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:44675 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 37831 invoked from network); 3 Jul 2009 09:41:39 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jul 2009 09:41:39 -0000 Authentication-Results: pb1.pair.com header.from=rquadling@googlemail.com; sender-id=pass; domainkeys=bad Authentication-Results: pb1.pair.com smtp.mail=rquadling@googlemail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain googlemail.com designates 209.85.218.206 as permitted sender) DomainKey-Status: bad X-DomainKeys: Ecelerity dk_validate implementing draft-delany-domainkeys-base-01 X-PHP-List-Original-Sender: rquadling@googlemail.com X-Host-Fingerprint: 209.85.218.206 mail-bw0-f206.google.com Received: from [209.85.218.206] ([209.85.218.206:62008] helo=mail-bw0-f206.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id C6/E8-27980-052DD4A4 for ; Fri, 03 Jul 2009 05:41:37 -0400 Received: by bwz2 with SMTP id 2so1653357bwz.23 for ; Fri, 03 Jul 2009 02:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:reply-to:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=JuWg3GCghS3rONCIIJ6OFWtqmCaHyfEJzf/YvskbibE=; b=Q14SSmgx+AjyyN1DO0KGcMfSD/WvCtI5Cj0vii2ue0nX9sTr/F/tyqV3TpweNl0hGI briXE7ecSbWSQI+l99kUbO3yj1vJiC25pUzsFoPX6i5kIZTL4qaJngV2P8KA50/RM5VN 9KYCaZox7VMQP1jajMoECLDdOT55DRipFFAhU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; b=CD1p5Go+IFr16oKP3/qnI9bT/Ms8fxGN/C13UdWlQIGBgNs3EYnb9faQ5T6qotyCMF qOf9/m3KTSu2na4T8FgJS+rbn9WW3NexVhtrzkNy2DJqGmQvxmtYY3fE/T+tOAP0DzO7 217R6uT0o5z7AyQKywiLjYp3TehxkZViSADP4= MIME-Version: 1.0 Received: by 10.223.111.140 with SMTP id s12mr730151fap.45.1246614093595; Fri, 03 Jul 2009 02:41:33 -0700 (PDT) Reply-To: RQuadling@googlemail.com In-Reply-To: <4A4CE77F.2090302@zend.com> References: <4A4BA5C8.1020204@zend.com> <10845a340907020525x786a196dv4959d522675ca6eb@mail.gmail.com> <4A4CE77F.2090302@zend.com> Date: Fri, 3 Jul 2009 10:41:13 +0100 Message-ID: <10845a340907030241g1edcf8carc219683da69e1106@mail.gmail.com> To: Stanislav Malyshev Cc: Ilia Alshanetsky , PHP internals Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3 From: rquadling@googlemail.com (Richard Quadling) 2009/7/2 Stanislav Malyshev : > It's not about the user input and security - it's about having different > parts of your code working together through all possible changes. If you've > got strict API you've got to make sure what you are sending to it would pass > those strict checks, and would keep doing so through all changes done to the > code. Hmm. Sounds like a programmers job you're describing there. I wonder if the split is between people coming to PHP from web design (JavaScript/Perl) and coming to PHP from other programming languages (VB/Java/C++/COBOL/ColdFusion - a long list [1]). I've mainly come from a Delphi's Object Pascal and Sage Retrieve 4GL (syntatically a mix of COBOL and Pascal). >> A big +1 from me to incorporate type hinting into PHP. > > I think calling this proposal "type hinting" just confuses the discussion. > It's (optional) strict typing and it should be called so. Maybe this could be solved easier and made more acceptable to all sides if rather than calling it "type hinting" / "(optional) strict typing" it was called "auto casting". A significant issue is what happens when the variables supplied are NOT of the appropriate type. I agree with Stanislav in that developers could end up with having to "stuff their code with explicit type conversions". Inside the function/method, we are wanting to essentially force the inputs to match the requirements. So, rather than have the "explicit type conversions" being performed by users of the libraries, why not incorporate the conversions into the function/method declaration? If the data coming in is weakly typed, and we are wanting a specific type, we are going to cast it (currently). Casting is going to take place somewhere. Currently, you can use docblocks to suggest the type (no enforcement). If a user DOES read the docblocks and casts it, it doesn't actually help anyone as PHP is known to be weakly typed, so the library developer STILL has to do checks of some sort. But. If autocasting was available, users could RELY on the fact that PHP will use its built-in, well known and documented type-juggling logic to cast the supplied userland data to the libraries required type. This is now really utilising PHP's type-juggling to intelligently provide library developers with optional strict-typing. It incorporates type hinting, so a library user can do the casting if they want (I assume PHP does nothing for (string)"1" or (int)4, etc.) Essentially auto casting would remove having to manually cast data at all. Regards, Richard. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems -- ----- Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731 "Standing on the shoulders of some very clever giants!" I need a car : http://snipurl.com/l4pih ZOPA : http://uk.zopa.com/member/RQuadling