Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:48418 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 5882 invoked from network); 24 May 2010 05:54:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 May 2010 05:54:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 74.85.23.205 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 74.85.23.205 mail.sugarcrm.net Windows 2000 SP2+, XP SP1 (seldom 98 4.10.2222) Received: from [74.85.23.205] ([74.85.23.205:41683] helo=mail.sugarcrm.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 38/42-21629-2841AFB4 for ; Mon, 24 May 2010 01:54:11 -0400 Received: from StasMacBook.local (98.210.181.235) by exch-cupertino1.cup1.sugarcrm.net (10.8.1.103) with Microsoft SMTP Server (TLS) id 8.1.393.1; Sun, 23 May 2010 22:54:07 -0700 Message-ID: <4BFA147F.4090307@sugarcrm.com> Date: Sun, 23 May 2010 22:54:07 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: References: <7.0.1.0.2.20100522175819.0a601c68@zend.com> <65101.93.108.152.52.1274662417.squirrel@www.geleia.net> <7.0.1.0.2.20100524075150.16056330@zend.com> In-Reply-To: <7.0.1.0.2.20100524075150.16056330@zend.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Type hinting From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > I see three key options going forward: > 1. Implement the table along the lines of what it looks like now, > perhaps with minor changes. > 2. Implement identical conversion rules to the ones that exist in > PHP; That effectively turns type hinting into scalar casting > operators (not saying that's a bad thing!) > 3. Implement identical conversion rules to the ones that exist in > PHP, except for when they really suck. Namely, lose the > array->scalar conversions and silent conversions of non-numeric > strings to numbers. I'm for 3, Array->scalar must die, as for non-numeric to numbers, I don't have strong opinion as I see no point in it, IMO if it failed, I'd be OK with it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227