Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34428
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain interjinn.com from 66.11.173.122 cause and error)
To: Lukas Kahwe Smith <mls@pooteeweet.org>
Cc: Pierre <pierre.php@gmail.com>, Marcus Boerger <helly@php.net>, Gregory Beaver <greg@chiaraquartet.net>, Alain Williams <addw@phcomp.co.uk>, internals Mailing List <internals@lists.php.net>
In-Reply-To: <232B1227-ECF4-4AC6-89C5-6179478A51DF@pooteeweet.org>
References: <477DB7BF.10201@chiaraquartet.net>
	 <20080104105558.GC7861@mint.phcomp.co.uk>
	 <477E5649.2080104@chiaraquartet.net>
	 <fe05d1540801040853q1b053a04gf4ad028e19a84e4d@mail.gmail.com>
	 <fe05d1540801040853w20c9f054i2e697764761431c9@mail.gmail.com>
	 <1463438959.20080104182050@marcus-boerger.de>
	 <fe05d1540801040923m16c616bcge29ea73f931d2072@mail.gmail.com>
	 <1199468241.6629.53.camel@blobule>
	 <232B1227-ECF4-4AC6-89C5-6179478A51DF@pooteeweet.org>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Organization: InterJinn
Date: Fri, 04 Jan 2008 12:51:09 -0500
Message-ID: <1199469069.6629.62.camel@blobule>
Mime-Version: 1.0
Subject: Re: [PHP-DEV] type hinting
From: robert@interjinn.com (Robert Cummings)

On Fri, 2008-01-04 at 18:44 +0100, Lukas Kahwe Smith wrote:
> On Jan 4, 2008, at 6:37 PM, Robert Cummings wrote:
> 
> > On Fri, 2008-01-04 at 18:23 +0100, Pierre wrote:
> >> On Jan 4, 2008 6:20 PM, Marcus Boerger <helly@php.net> wrote:
> >>> Hello Pierre,
> >>>
> >>>  we never accepted this as a pro argument. Infact we often saw the
> >>> necessaity to highlight something is optional to vote against it.  
> >>> We do this
> >>> for a reason. That is we only want to support mainstream features.
> >>
> >> My point of view is that this feature should be a mainstream feature.
> >> To make it optional was to lower the issues for those who don't care
> >> about argument strictness. We did not give them this choice for the  
> >> OO
> >> strictness.
> >
> > IMHO, optionally inclusion of type hinting for functions/methods can
> > only be a boon to code quality and readability. IMHO when a type  
> > hint is
> > provided and a parameter doesn't match the type hint then I think a
> > fatal error should occur. This forces the user of the function that  
> > has
> > type hinting to ensure their data is of the correct type. This  
> > prevents
> > accidental wrong data conversion. However, I see the other side of the
> > coin too where automatic type conversion could be desirable also.
> 
> Fatal error is a no no. This goes back to my argument of why  
> exceptions do not fit the PHP development process as uncaught  
> exceptions are also fatal errors. The reason is that PHP is great  
> because it works as good as is reomotely possible with the given code.  
> Look at SugarCRM, the code is horrific, yet it works (more or less).  
> This is especially a concern for me when doing refactoring types are  
> surely going to mismatch during the process, but as I test some parts  
> of my changes, I do not want the entire application to fail until I  
> complete my refactoring.
> 
> Fatal errors everywhere are a nice way to beat developers to write  
> finished code from day one (or actually before any refresh), which  
> matches the development style how exactly how many PHP developers?
> 
> But we are only talking about an E_RECOVERABLE. That being said the  
> argument brought up by Greg about the lack of context still applies so  
> maybe it should just be a warning or whatever ..

You are right, E_RECOVERABLE is a much better option.

Cheers,
Rob.
-- 
...........................................................
SwarmBuy.com - http://www.swarmbuy.com

    Leveraging the buying power of the masses!
...........................................................