Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:34393 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 48766 invoked by uid 1010); 4 Jan 2008 04:36:17 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 48751 invoked from network); 4 Jan 2008 04:36:17 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jan 2008 04:36:17 -0000 Authentication-Results: pb1.pair.com smtp.mail=greg@chiaraquartet.net; spf=permerror; sender-id=unknown Authentication-Results: pb1.pair.com header.from=greg@chiaraquartet.net; sender-id=unknown Received-SPF: error (pb1.pair.com: domain chiaraquartet.net from 38.99.98.18 cause and error) X-PHP-List-Original-Sender: greg@chiaraquartet.net X-Host-Fingerprint: 38.99.98.18 beast.bluga.net Linux 2.6 Received: from [38.99.98.18] ([38.99.98.18:33728] helo=mail.bluga.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id E3/CE-20810-EB7BD774 for ; Thu, 03 Jan 2008 23:36:16 -0500 Received: from mail.bluga.net (localhost.localdomain [127.0.0.1]) by mail.bluga.net (Postfix) with ESMTP id E57D7C0F9FC for ; Thu, 3 Jan 2008 21:36:10 -0700 (MST) Received: from [192.168.0.106] (CPE-76-84-11-224.neb.res.rr.com [76.84.11.224]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.bluga.net (Postfix) with ESMTP id 9D290C0F9F3 for ; Thu, 3 Jan 2008 21:36:10 -0700 (MST) Message-ID: <477DB7BF.10201@chiaraquartet.net> Date: Thu, 03 Jan 2008 22:36:15 -0600 User-Agent: Thunderbird 2.0.0.6 (X11/20071022) MIME-Version: 1.0 To: internals Mailing List X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: type hinting From: greg@chiaraquartet.net (Gregory Beaver) Hi all, As someone who has dealt with many scripts written by others as well as many of my own in a large-scale project (PEAR). I can say with absolute certainty that scalar type hints would not make my job easier. In fact, it would make it harder. Many of the functions I work with require varied input and almost always require some kind of validation of that input. A built-in procedure that would either end execution with a fatal error or suddenly jump execution to a global error handler that has no idea of the context in which the error was triggered is almost as useful to me as a PHP extension that runs the pump on an inflatable chicken (at least the inflatable chicken extension has some momentary amusement value). Where is the increased value? Saving a few keystrokes of validation? No. You still need to validate the input for range, or is_numeric() or some other fancy business. Easier error handling? Most definitely not. Most of the time, I throw an exception, how is an E_FATAL or E_RECOVERABLE_ERROR going to help me here? False sense of security because it limits input to a particular type? perhaps, but the key word here is "false." type hints might be more useful if they threw an exception, but even then I would rather do that explicitly for the obvious reason that I may not be the maintainer of my programs forever and someone else is going to have to figure out why this exception was thrown. The backtrace will reference an actual line number with the word "throw" on it if I do it myself, and will be magical if not. In short, could we please move on from type hinting, I am a big -1 for so many reasons, it gives me gas just to think about them all at once. Thanks, Greg