Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34424
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain pooteeweet.org from 85.10.196.195 cause and error)
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>
Message-ID: <232B1227-ECF4-4AC6-89C5-6179478A51DF@pooteeweet.org>
To: Robert Cummings <robert@interjinn.com>
In-Reply-To: <1199468241.6629.53.camel@blobule>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Fri, 4 Jan 2008 18:44:29 +0100
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>
X-backendmedia-com-MailScanner-Information: Please contact the ISP for more information
X-backendmedia-com-MailScanner: Found to be clean
X-backendmedia-com-MailScanner-SpamCheck: not spam, SpamAssassin (not cached,
	score=0.134, required 6, AWL 0.03, RDNS_DYNAMIC 0.10)
X-backendmedia-com-MailScanner-From: mls@pooteeweet.org
X-Spam-Status: No
Subject: Re: [PHP-DEV] type hinting
From: mls@pooteeweet.org (Lukas Kahwe Smith)


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 ..

regards,
Lukas