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 <[EMAIL PROTECTED]> 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! ........................................................... -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
