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 ..
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
