Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:34329 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 14025 invoked by uid 1010); 3 Jan 2008 18:21:38 -0000 Delivered-To: ezmlm-scan-internals@lists.php.net Delivered-To: ezmlm-internals@lists.php.net Received: (qmail 14010 invoked from network); 3 Jan 2008 18:21:38 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 3 Jan 2008 18:21:38 -0000 Authentication-Results: pb1.pair.com header.from=tomi@cumulo.fi; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=tomi@cumulo.fi; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain cumulo.fi from 81.228.8.154 cause and error) X-PHP-List-Original-Sender: tomi@cumulo.fi X-Host-Fingerprint: 81.228.8.154 pne-smtpout4-sn2.hy.skanova.net Solaris 10 (beta) Received: from [81.228.8.154] ([81.228.8.154:34399] helo=pne-smtpout4-sn2.hy.skanova.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 19/07-20810-1B72D774 for ; Thu, 03 Jan 2008 13:21:37 -0500 Received: from [192.168.1.3] (84.250.46.16) by pne-smtpout4-sn2.hy.skanova.net (7.3.129) (authenticated as kaisto-9) id 471A7B0C003D958D for internals@lists.php.net; Thu, 3 Jan 2008 19:20:24 +0100 Organization: Cumulo Studio To: internals@lists.php.net Date: Thu, 3 Jan 2008 20:19:03 +0200 User-Agent: KMail/1.9.7 References: <200801031903.01980.tomi@cumulo.fi> <1199380881.15292.11.camel@sbarrow-desktop> In-Reply-To: <1199380881.15292.11.camel@sbarrow-desktop> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <200801032019.03957.tomi@cumulo.fi> Subject: Re: [PHP-DEV] RE: Optional scalar type hinting From: tomi@cumulo.fi (Tomi Kaistila) Yes it seems PHP will omit E_WARNING if you omit an argument. (Had to actually check.) Not a bad choice for an error and probably also easier to manage when you are dealing with complicated error handling in large applications. I would suggest E_WARNING or E_FATAL, but not E_NOTICE or E_STRICT, for the simple fact that they are ignore by a major portion of PHP developers and to use them would prompt a high risk of people writing bad code. Also, now that you mentioned abstract classes, type hinting might also be useful with interfaces. Tomi Kaistila PHP Developer On Thursday 03 January 2008 19:21:21 you wrote: > I think E_WARNING would be appropriate. That's what happens when you > omit an argument to a function right? > > And about function return type hinting, I don't think it would be as > useful as parameter type hinting, but it would be useful. Mostly for > stuff like declaring an abstract function in a parent class that must > return a certain type. > > class a { > abstract public function getNumber() returns int ; > } > class b extends a { > public function getNumber() { > return rand() * 3463 ; > } > } > class c extends a { > public function getNumber() { > return 'I\'m going to mess everything up by returning a string.' ; // > Would cause error with type hinting. > } > } > > On Thu, 2008-01-03 at 19:03 +0200, Tomi Kaistila wrote: > > Hello everyone > > > > I figured I would bring my opinion in to support of Sam's request for a > > more complete type hinting feature. Namely I am interested in the support > > for hinting scalar types on function and method arguments and I am sure > > it is safe for me to say that I speak for a lot of people. Most people > > that I know find the current type hinting, while useful, ridiculous > > because it looks like the job was left unfinished for whatever abstract > > reason. > > > > In my opinion type hinting should definitely be allowed for scalar > > values. As for return types, I am not so sure. So far I have found no use > > for such a feature in my own code, so I won't comment on it. If it is > > added, I welcome it for those who find it useful but if it is not added I > > will not loose sleep over it. > > > > > I was thinking at something along the lines of objects also for > > > instance: $i = new Integer(33); > > > > After my own experiments with the subject I concur that while it can be > > made to work, it is not only a bad idea (for the reasons mentioned > > earlier) it is also redundant and just unnecessary. There is a lot better > > way to accomplish the same and that by allowing scalar values to be > > hinted. It is simpler, cleaner, and easier to implement. > > > > > What if type hinting just generated an E_NOTICE. Nothing more for the > > > time being. > > > > Changing it to E_NOTICE or E_STRICT defeats the purpose somewhat since > > if I write a piece of code that hints that the argument for a-whatever > > method needs to be an integer it seems useless if the user of my library > > can avoid the issue just by supressing lesser errors and those who do not > > need to write extensive error handling code to respond to this sort of > > error (if they indeed deem it necessary to do so). > > > > While hinting is, and should remain, optional, when it is used it should > > be enforced. After all the user of my library has the option to dump it > > and go for another library that does not force types. That is the beauty > > of having options. > > > > Tomi Kaistila > > PHP Developer