Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:34348
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain iamjochem.com from 194.109.193.121 cause and error)
Message-ID: <477D477F.4010609@iamjochem.com>
Date: Thu, 03 Jan 2008 21:37:19 +0100
User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031)
MIME-Version: 1.0
To: Tomi Kaistila <tomi@cumulo.fi>
CC: internals@lists.php.net
References: <200801031903.01980.tomi@cumulo.fi> <477D2CDB.3000005@zend.com> <alpine.DEB.0.98.0801032022110.4763@kossu.ez.no> <200801032201.24355.tomi@cumulo.fi>
In-Reply-To: <200801032201.24355.tomi@cumulo.fi>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] RE: Optional scalar type hinting
From: jochem@iamjochem.com (Jochem Maas)

Tomi Kaistila schreef:
>> Broken record perhaps? I am getting a bit tired of this "just use Java
>> argument", it's perhaps even a bit arrogant. From what I read there is
>> plenty of people that want type hints for static types - there's a few
>> patches out there, it doesn't slow down the general case. So why should
>> we *not* add it? (And yes, I changed my mind)
> Same here. I am getting generally tired of the attitude some 
> politically-correct people seem to have about writing "javaish" code. What 
> the heck is "javaish" code anyway? Most features that exist in both PHP and 
> Java can also be found in myriad of other languages and it has so far not 
> stopped the development team from adding a feature when it is clearly useful 
> and (most importantly) desired an uncounted number of people.
> 
> In fact those who oppose the feature seem only capable of doing so with 
> hair-splitting rhetorics.
> 
>> am I the only one to consider E_FATAL (as generated for class typehints) 
>> makes type hinting useless - given that there is no compile stage at which 
>> to catch typehint related mistakes
> In principle you are correct. But E_FATAL errors should not happen in a 
> program that is in production use. If they do, it seems someone was not doing 
> their job properly.

you are right, they shouldn't - but who can say that every execution permutation has
been tested and hammered shut in their code (let alone someone else 3rd party lib or extension)?

in practice mistakes do occur - and saying someone has not been doing their job
properly is little consilation to the end user, client or manager (who gets a white screen of death) ...
there is no reason not to let the application try to gracefully handle a mistake
like this ... besides I was under the impression that E_FATAL meant the engine was
in an unstable state and was unable to continue execution - I don't see why a typehint
failure would cause an unstable engine state (rather the engine is presuming that
the code is *going* to create an unstable state if it were to continue ... which is
not very helpful in my book).

> 
> I am not convinced throwing an exception is the best course of action. If it 
> was, you might make the argument that all errors should be exceptions, while 
> traditionally it is the other way around and changing that is beyond the 
> scope of this thread. I actually like the current "division of labor" when it 
> comes to error handling.
> 
> When PHP detects an error, it should actually be an error. Exceptions are 
> convenient for the code that you as a PHP developer can throw. They are 
> especially a blessing when writing library code. That way exceptions work for 
> the error management, instead of competing with it.
> 
> I say use E_WARNING at this stage. If there is some large redecorating with 
> PHP's error handling in the future, it can be changed then.

that is a very sane arguement. I'll have to concede :-)

> 
> Tomi Kaistila
> PHP Developer
>