Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:34609 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 54806 invoked by uid 1010); 8 Jan 2008 20:51:24 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 54787 invoked from network); 8 Jan 2008 20:51:24 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 8 Jan 2008 20:51:24 -0000 Authentication-Results: pb1.pair.com smtp.mail=tomi@cumulo.fi; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=tomi@cumulo.fi; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cumulo.fi from 81.228.11.120 cause and error) X-PHP-List-Original-Sender: tomi@cumulo.fi X-Host-Fingerprint: 81.228.11.120 pne-smtpout3-sn1.fre.skanova.net Solaris 10 (beta) Received: from [81.228.11.120] ([81.228.11.120:62204] helo=pne-smtpout3-sn1.fre.skanova.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 9C/CD-38195-442E3874 for ; Tue, 08 Jan 2008 15:51:19 -0500 Received: from [192.168.1.3] (84.250.46.16) by pne-smtpout3-sn1.fre.skanova.net (7.3.129) (authenticated as kaisto-9) id 478149BD00020A67 for internals@lists.php.net; Tue, 8 Jan 2008 21:50:15 +0100 Organization: Cumulo Studio To: internals@lists.php.net Date: Tue, 8 Jan 2008 22:47:51 +0200 User-Agent: KMail/1.9.7 References: <200801081603.35826.tomi@cumulo.fi> <1199803721.15292.269.camel@sbarrow-desktop> In-Reply-To: <1199803721.15292.269.camel@sbarrow-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200801082247.51805.tomi@cumulo.fi> Subject: Re: [PHP-DEV] type hinting From: tomi@cumulo.fi (Tomi Kaistila) > But the syntax is longer ("$a = 5" vs "$a = new Integer(5)"), and if you > have a large application with hundreds of integers it starts to add up. > Performance is also much worse when using objects for every variable. I agree. That is what I meant by "ugly" and "clumsy" in my last post. > > This sounds like, at least, a partial victory to adding proper type > > hinting to PHP but in my mind it is not enough. I have counted that about > > a quarter of all type hints that I would make is about matching the > > argument's type to scalar. The rest are about separating specific scalars > > from each other. In most cases integer and boolean. > > Better than nothing. No, it is not. It is actually better to not fix it at all, if you cannot fix it properly. Especially in this case when the feature has already once been left "unfinished". The benefit is zero for me, if when I need to hint a boolean and can only hint a scalar. In that case, I will still have to do the validating myself. I might as well leave the type hinting out all together, instead of waste resources for having first PHP check that it is a scalar and then my own code to check that it is a boolean. Actually, if I can only hint "scalar" in general, I am essentially telling the users of my API that they should be ready for two types of errors. That which occurs when the argument is not a scalar and that which occurs when it is not a boolean. One will be a PHP error and the second will be an exception. Would be easier on them if I do not use type hinting at all in that case. I say, do it properly or do not do it at all. Tomi Kaistila PHP Developer