# type hinting

- Thread: https://externals.io/message/34393
- Original archive: https://news-web.php.net/php.internals/34393
- Started by Gregory Beaver on 2008-01-04T04:36:15+00:00
- Messages: 94
- Page 1 of 4: messages 1 to 25 (25 per page, add `?page=N` to the URL)
- Next page: https://externals.io/message/34393.md?page=2
- Reply by email to internals@lists.php.net
- More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt

---

## #34393 — Gregory Beaver — 2008-01-04T04:36:15+00:00

URL: https://externals.io/message/34393#34393

Hi all,

As someone who has dealt with many scripts written by others as well as
many of my own in a large-scale project (PEAR).  I can say with absolute
certainty that scalar type hints would not make my job easier.

In fact, it would make it harder.  Many of the functions I work with
require varied input and almost always require some kind of validation
of that input.  A built-in procedure that would either end execution
with a fatal error or suddenly jump execution to a global error handler
that has no idea of the context in which the error was triggered is
almost as useful to me as a PHP extension that runs the pump on an
inflatable chicken (at least the inflatable chicken extension has some
momentary amusement value).

Where is the increased value?  Saving a few keystrokes of validation? 
No.  You still need to validate the input for range, or `is_numeric()` or
some other fancy business.  Easier error handling?  Most definitely
not.  Most of the time, I throw an exception, how is an E_FATAL or
 `E_RECOVERABLE_ERROR` going to help me here?  False sense of security
because it limits input to a particular type?  perhaps, but the key word
here is "false."

type hints might be more useful if they threw an exception, but even
then I would rather do that explicitly for the obvious reason that I may
not be the maintainer of my programs forever and someone else is going
to have to figure out why this exception was thrown.  The backtrace will
reference an actual line number with the word "throw" on it if I do it
myself, and will be magical if not.

In short, could we please move on from type hinting, I am a big -1 for
so many reasons, it gives me gas just to think about them all at once.

Thanks,
Greg

---

## #34400 — Alain Williams — 2008-01-04T10:55:58+00:00

URL: https://externals.io/message/34393#34400 · In reply to: #34393

> Hi all,
> 
> As someone who has dealt with many scripts written by others as well as
> many of my own in a large-scale project (PEAR).  I can say with absolute
> certainty that scalar type hints would not make my job easier.
> 
> In fact, it would make it harder.  Many of the functions I work with
> require varied input and almost always require some kind of validation
> of that input.  A built-in procedure that would either end execution
> with a fatal error or suddenly jump execution to a global error handler
> that has no idea of the context in which the error was triggered is
> almost as useful to me as a PHP extension that runs the pump on an

You are missing the point.
If you want your function to take an argument of arbitrary type, then
you simply don't give a type hint[**]

[**] I suppose that we might implement the type hint 'mixed' which would
have the same effect as no type hint. Some people might like this from
the 'internal documentation' point of view.

> Where is the increased value?  Saving a few keystrokes of validation? 
> No.  You still need to validate the input for range, or `is_numeric()` or

No. The point is NOT to save input ($_GET, etc) validation -- that will
still need to be done; the point is to help pick up programming errors
where you accidentally get the type wrong.

Granted: some idiots will use it as cheap input validation, but it is difficult
to help some people.

-- 
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

---

## #34401 — Sam Barrow — 2008-01-04T13:20:47+00:00

URL: https://externals.io/message/34393#34401 · In reply to: #34400

> 
> > […]
> 
> You are missing the point.
> If you want your function to take an argument of arbitrary type, then
> you simply don't give a type hint[**]
> 
> [**] I suppose that we might implement the type hint 'mixed' which would
> have the same effect as no type hint. Some people might like this from
> the 'internal documentation' point of view.

I was thinking about this, a "mixed" type hint which doesn't do
anything. Would be very easy to add.

> > […]
> 
> No. The point is NOT to save input ($_GET, etc) validation -- that will
> still need to be done; the point is to help pick up programming errors
> where you accidentally get the type wrong.
> 
> Granted: some idiots will use it as cheap input validation, but it is difficult
> to help some people.

Exactly. This is not intended for $_REQUEST stuff. This is intended for
internal function interaction, configuration variables, etc. All
post/get data is inputted as strings, so this doesn't apply there.

---

## #34407 — Gregory Beaver — 2008-01-04T15:52:41+00:00

URL: https://externals.io/message/34393#34407 · In reply to: #34400

Alain Williams wrote:
> 
>   
> > […]
>
> You are missing the point.
> If you want your function to take an argument of arbitrary type, then
> you simply don't give a type hint[**]
>   
But I *don't* want my functions to take an argument of arbitrary type -
it is in fact you who are missing the point.  A type hint is a poor
solution to a real problem that is much more easily solved via simple
input validation and graceful error handling.  The current situation in
PHP provides a much more flexible solution to the same problem.

Many users out there are confused about simple things like the result of
1 === "1" versus 1 == "1".  The fact is that scalar types are simply not
strict enough to warrant a type hint.  An object of class X is immutable
- you either have that or a subclass.  An array is an array, and can't
look like anything else.  Integers, floats, strings are much more gray
area, and much less likely to provide good, clear input to check against
a type hint.

Also, you and many who are in favor of type hints seem to forget that
part of PHP's strength is the ability to distribute and use code written
by other people.  I guarantee that regardless of whether I choose to use
type hints, someone whose code I will have to use will be using type
hints, forcing me to deal with them.  Imagine a program uses exceptions
for error handling, and you wish to use a library that has type hints. 
Now, you can't catch problems using this program except via fatal error,
or worse, an error handler that has only a backtrace from which to grab
context.
> [**] I suppose that we might implement the type hint 'mixed' which would
> have the same effect as no type hint. Some people might like this from
> the 'internal documentation' point of view.
>
>   
> > […]
>
> No. The point is NOT to save input ($_GET, etc) validation -- that will
> still need to be done; the point is to help pick up programming errors
> where you accidentally get the type wrong.
This is just the point that appears to be lost on advocates for scalar
type hints - this work of picking up programming errors should be
performed in development, not in production, and type hint as warning
does nothing to assist debugging.  In the error log, there is no
backtrace, so all you know is that on line X in file Y invalid input was
passed to a function.  No context, no reproduce steps, and no backtrace
to see the logic train.

Greg

---

## #34408 — Sam Barrow — 2008-01-04T16:05:57+00:00

URL: https://externals.io/message/34393#34408 · In reply to: #34407

> Alain Williams wrote:
> > […]
> But I *don't* want my functions to take an argument of arbitrary type -
> it is in fact you who are missing the point.  A type hint is a poor
> solution to a real problem that is much more easily solved via simple
> input validation and graceful error handling.  The current situation in
> PHP provides a much more flexible solution to the same problem.
> 
> Many users out there are confused about simple things like the result of
> 1 === "1" versus 1 == "1".  The fact is that scalar types are simply not
> strict enough to warrant a type hint.  An object of class X is immutable
> - you either have that or a subclass.  An array is an array, and can't
> look like anything else.  Integers, floats, strings are much more gray
> area, and much less likely to provide good, clear input to check against
> a type hint.
> 
> Also, you and many who are in favor of type hints seem to forget that
> part of PHP's strength is the ability to distribute and use code written
> by other people.  I guarantee that regardless of whether I choose to use
> type hints, someone whose code I will have to use will be using type
> hints, forcing me to deal with them.  Imagine a program uses exceptions
> for error handling, and you wish to use a library that has type hints. 
> Now, you can't catch problems using this program except via fatal error,
> or worse, an error handler that has only a backtrace from which to grab
> context.
> > […]
> This is just the point that appears to be lost on advocates for scalar
> type hints - this work of picking up programming errors should be
> performed in development, not in production, and type hint as warning
> does nothing to assist debugging.  In the error log, there is no
> backtrace, so all you know is that on line X in file Y invalid input was
> passed to a function.  No context, no reproduce steps, and no backtrace
> to see the logic train.

That's not true. You can easily set up your error handler to throw an
exception, which will provide a full backtrace.

And type hinting will help to catch these errors in development, rather
than finding out that all of your users have their email addresses
stored as "Array" in your database.

> Greg

---

## #34409 — Stefan Esser — 2008-01-04T16:41:00+00:00

URL: https://externals.io/message/34393#34409 · In reply to: #34407

Good Morning everyone,

one should not forget that type hinting has some clear advantages the
anti type hinting advocates always try to forget...

* the code gets smaller because not so many typechecks in every function
* because the code gets smaller it is faster executed (userspace
typecheck is slower than "engine-space")
* without all these type checks the code gets easier to read
* with type hints byte code optimizer can optimize the code far better
-> faster execution
* with type hints static analysing tools that check for
bugs/vulnerabilities can perform far better (intra procedural analysis
gives more information)

Stefan Esser

---

## #34410 — Ilia Alshanetsky — 2008-01-04T16:51:32+00:00

URL: https://externals.io/message/34393#34410 · In reply to: #34409

To add another two points to Stefan's argument. Type hinting does not  
remove the need to filter user input, but it does allow you to safe- 
guard internal functions (library code etc...) against accidental or  
internal misuse or improper handling of the data in the front-end  
layer. It also makes the code far more readable and understandable not  
the mention help doc generation tools that interrogate the code.




> Good Morning everyone,
>
> one should not forget that type hinting has some clear advantages the
> anti type hinting advocates always try to forget...
>
> * the code gets smaller because not so many typechecks in every  
> function
> * because the code gets smaller it is faster executed (userspace
> typecheck is slower than "engine-space")
> * without all these type checks the code gets easier to read
> * with type hints byte code optimizer can optimize the code far better
> -> faster execution
> * with type hints static analysing tools that check for
> bugs/vulnerabilities can perform far better (intra procedural analysis
> gives more information)
>
> Stefan Esser
>
> -- 
> 
> 
>

Ilia Alshanetsky

---

## #34411 — Pierre — 2008-01-04T16:53:07+00:00

URL: https://externals.io/message/34393#34411 · In reply to: #34407

> But I *don't* want my functions to take an argument of arbitrary type -
> it is in fact you who are missing the point.  A type hint is a poor
> solution to a real problem that is much more easily solved via simple
> input validation and graceful error handling.  The current situation in
> PHP provides a much more flexible solution to the same problem.

Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use
it. You still like to take care of any kind of types for your
arguments (with all associated magical pains and useless tests), you
can do it. That's not the case for use who likes to use stronger
arguments (and we are talking about arguments only here).

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #34412 — Pierre — 2008-01-04T16:53:56+00:00

URL: https://externals.io/message/34393#34412 · In reply to: #34411

> 
>
> > […]
>
> Unlike our OO strictness (E_FATAL!!), nothing will prevent you to use

Read: othing will prevent you to >do not< use it :)

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #34413 — Sam Barrow — 2008-01-04T16:54:35+00:00

URL: https://externals.io/message/34393#34413 · In reply to: #34409

> Good Morning everyone,
> 
> one should not forget that type hinting has some clear advantages the
> anti type hinting advocates always try to forget...
> 
> * the code gets smaller because not so many typechecks in every function

True.

> * because the code gets smaller it is faster executed (userspace
> typecheck is slower than "engine-space")

Very true, type hinting would be many times faster than using is_int,
etc. which puts to rest any argument that type hinting will be bad for
performance.

> * without all these type checks the code gets easier to read

Yes, more concise and compact without manual type checking.

> * with type hints byte code optimizer can optimize the code far better
> -> faster execution
> * with type hints static analysing tools that check for
> bugs/vulnerabilities can perform far better (intra procedural analysis
> gives more information)

Also true. Applications like PHPDocumentor could make good use of scalar
type hints.

> 
> Stefan Esser

---

## #34414 — Sam Barrow — 2008-01-04T17:01:10+00:00

URL: https://externals.io/message/34393#34414 · In reply to: #34412

> 
> > […]
> 
> Read: othing will prevent you to >do not< use it :)
> 

So you're saying if you don't like it just don't use it?

---

## #34415 — Sam Barrow — 2008-01-04T17:03:38+00:00

URL: https://externals.io/message/34393#34415 · In reply to: #34410

> To add another two points to Stefan's argument. Type hinting does not  
> remove the need to filter user input, but it does allow you to safe- 
> guard internal functions (library code etc...) against accidental or  
> internal misuse or improper handling of the data in the front-end  
> layer. It also makes the code far more readable and understandable not  
> the mention help doc generation tools that interrogate the code.
> 

Exactly, not input, but internal application code. For me a big thing is
configuration variables which are then used to call functions. It would
also help any other developers looking at your code (easier to
understand the purpose of arguments to a functions if it is type
hinted).

> 
> 
> 
> > […]
> 
> Ilia Alshanetsky

---

## #34416 — Pierre — 2008-01-04T17:09:02+00:00

URL: https://externals.io/message/34393#34416 · In reply to: #34414

>
> 
> > […]
>
> So you're saying if you don't like it just don't use it?

Yes, that's the meaning of "optional" I suppose :)

My idea about it (I did not test the patch, so correct me if I
misunderstood the proposal) was to leave the default as it is now:

function($a) > what Greg likes to always use ;)
function(mixed $a) > little syntax sugar, same as the previous one
function(int $a)
etc.

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #34417 — Sam Barrow — 2008-01-04T17:11:41+00:00

URL: https://externals.io/message/34393#34417 · In reply to: #34416

> 
> > […]
> 
> Yes, that's the meaning of "optional" I suppose :)
> 
> My idea about it (I did not test the patch, so correct me if I
> misunderstood the proposal) was to leave the default as it is now:
> 
> function($a) > what Greg likes to always use ;)
> function(mixed $a) > little syntax sugar, same as the previous one
> function(int $a)
> etc.
> 

Exactly. I just added the "mixed" type hint which is the same as using
no type hint. The new patch is attached.

Extra keywords (real, long, double, etc.) have been taken out. The
available type hints are now mixed, int, float, bool, string, scalar,
num, resource, and object. And of course array and class type hints
still work.

---

## #34418 — Marcus Boerger — 2008-01-04T17:20:50+00:00

URL: https://externals.io/message/34393#34418 · In reply to: #34412

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.

marcus

Friday, January 4, 2008, 5:53:56 PM, you wrote:

> 
> > […]

> Read: othing will prevent you to >do not< use it :)

> -- 
> Pierre
> http://blog.thepimp.net | http://www.libgd.org




Best regards,
 Marcus

---

## #34419 — Sam Barrow — 2008-01-04T17:21:12+00:00

URL: https://externals.io/message/34393#34419 · In reply to: #34407

> Alain Williams wrote:
> > […]
> But I *don't* want my functions to take an argument of arbitrary type -
> it is in fact you who are missing the point.  A type hint is a poor
> solution to a real problem that is much more easily solved via simple
> input validation and graceful error handling.  The current situation in
> PHP provides a much more flexible solution to the same problem.
> 

Are you suggesting that if a function requires an integer, string, and
object, we use is_int, is_string, and is_object to trigger errors? What
if we have 50 functions like this?

With type hinting:

function a(int $a, string $b, object $c) {
	
}

Without type hinting:

function a($a, $b, $c) {
	if (!is_int($a)) {
		trigger_error(E_WHATEVER, 'Argument 1 to function a() must be an
integer.') ;
	}
	if (!is_string($b)) {
		trigger_error(E_WHATEVER, 'Argument 2 to function a() must be an
integer.') ;
	}
	if (!is_object($c)) {
		trigger_error(E_WHATEVER, 'Argument 3 to function a() must be an
integer.') ;
	}
}

---

## #34420 — Pierre — 2008-01-04T17:23:13+00:00

URL: https://externals.io/message/34393#34420 · In reply to: #34418

> 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.

-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

---

## #34421 — Lars Strojny — 2008-01-04T17:30:41+00:00

URL: https://externals.io/message/34393#34421 · In reply to: #34417

Hi Sam,

Am Freitag, den 04.01.2008, 12:11 -0500 schrieb Sam Barrow:
[...]
> Exactly. I just added the "mixed" type hint which is the same as using
> no type hint. The new patch is attached.
[...]

To make your patch better you should add a bunch of test cases. Just a
test brainstorming:
      * Current behaviour (no type hinting) works as expected
      * Current behaviour for class type hinting works
      * Scalar type hints are enforced to be lowercase ("Int" hints a
        class, "int" a primitive)
      * All new type hints work
      * All new type hint aliases work
      * All new type hints throw errors if wrong types are passed
      * Meta type hints (like "mixed", "num", etc.) work
      * Reflections on type hints work (foo(string $str);
        ReflectionParam::getType() => "string",
        ReflectionParam::isArray() => false and the like)

There are already a few test cases for type hinting in
tests/classes/type_hinting_*.phpt for you to look at.

cu, Lars

---

## #34422 — Robert Cummings — 2008-01-04T17:37:19+00:00

URL: https://externals.io/message/34393#34422 · In reply to: #34420

> 
> > […]
> 
> 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.
Perhaps a mixed solution would be viable?

<?php

function foo( require int $a, require string $b ){}

foo( '5', 'bleh' );  // <-- fatal error

?>

Contrast versus:

<?php

function foo( int $a, string $b ){}

foo( '5', 'bleh' );  // <-- no exception or error $a in foo() will
                     //     be type int (automatic conversion)

?>

Versus (still allowed default style):

<?php

function foo( $a, $b ){}

foo( '5', 'bleh' );  // <-- no exceptions or type conversions

?>

Thoughts?

Cheers,
Rob.
-- 
...........................................................
SwarmBuy.com - http://www.swarmbuy.com

    Leveraging the buying power of the masses!
...........................................................

---

## #34423 — Sam Barrow — 2008-01-04T17:41:24+00:00

URL: https://externals.io/message/34393#34423 · In reply to: #34422

> 
> > […]
> 
> 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.
> Perhaps a mixed solution would be viable?
> 

I don't think conversion would make sense here, as PHP will
automatically convert the variable before you use it anyway. Hinting
will prevent mistakes, conversion will just try to ignore them, which is
what PHP does already.

> <?php
> 
> function foo( require int $a, require string $b ){}
> 
> foo( '5', 'bleh' );  // <-- fatal error
> 
> ?>
> 
> Contrast versus:
> 
> <?php
> 
> function foo( int $a, string $b ){}
> 
> foo( '5', 'bleh' );  // <-- no exception or error $a in foo() will
>                      //     be type int (automatic conversion)
> 
> ?>
> 
> Versus (still allowed default style):
> 
> <?php
> 
> function foo( $a, $b ){}
> 
> foo( '5', 'bleh' );  // <-- no exceptions or type conversions
> 
> ?>
> 
> Thoughts?
> 
> Cheers,
> Rob.
> -- 
> ...........................................................
> SwarmBuy.com - http://www.swarmbuy.com
> 
>     Leveraging the buying power of the masses!
> ...........................................................

---

## #34424 — Lukas Kahwe Smith — 2008-01-04T17:44:29+00:00

URL: https://externals.io/message/34393#34424 · In reply to: #34422

> 
> > […]
>
> 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

---

## #34425 — Alain Williams — 2008-01-04T17:46:00+00:00

URL: https://externals.io/message/34393#34425 · In reply to: #34417

> Exactly. I just added the "mixed" type hint which is the same as using
> no type hint. The new patch is attached.
> 
> Extra keywords (real, long, double, etc.) have been taken out. The
> available type hints are now mixed, int, float, bool, string, scalar,
> num, resource, and object. And of course array and class type hints
> still work.

I notice that you use `strcasecmp()` to compare type name. I thought that we were moving
away from case independence, ie the type should be 'int' or perhaps 'INT' - whatever
we agree on it should have a defined capitalisation.

Just an off the wall thought ... if the type is not a known scalar type or class, then check to see if the
word is a constant ... could be interesting .... aka C's typedefs.

-- 
Alain Williams
Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer.
+44 (0) 787 668 0256  http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php
Chairman of UKUUG: http://www.ukuug.org/
#include <std_disclaimer.h

---

## #34427 — Sam Barrow — 2008-01-04T17:48:22+00:00

URL: https://externals.io/message/34393#34427 · In reply to: #34425

> 
> 
> > […]
> 
> I notice that you use `strcasecmp()` to compare type name. I thought that we were moving
> away from case independence, ie the type should be 'int' or perhaps 'INT' - whatever
> we agree on it should have a defined capitalisation.

Oh ok. Well I assumed it would be case sensitive like variables but you
do have a point, many keywords in PHP are not case sensitive. This is
something that can be easily changed depending on what people want.

> Just an off the wall thought ... if the type is not a known scalar type or class, then check to see if the
> word is a constant ... could be interesting .... aka C's typedefs.

---

## #34426 — Robert Cummings — 2008-01-04T17:48:28+00:00

URL: https://externals.io/message/34393#34426 · In reply to: #34423

> 
> > […]
> 
> I don't think conversion would make sense here, as PHP will
> automatically convert the variable before you use it anyway. Hinting
> will prevent mistakes, conversion will just try to ignore them, which is
> what PHP does already.

I think that depends on what I do with the variable. PHP doesn't know
how I intend to use it, and if I know I want an int and I don't want to
test for browserland garbage in my variable everytime the function is
called, then an automatic type conversion to int for my function can
make perfect sense. Yes, I could force the developer using my function
to cast the parameter as an int, but I'm certain conversion in the
engine without a userland cast is faster, and it makes it more
convenient to the consumer of my function since they can still treat it
like a classic function.

Cheers,
Rob.
-- 
...........................................................
SwarmBuy.com - http://www.swarmbuy.com

    Leveraging the buying power of the masses!
...........................................................

---

## #34428 — Robert Cummings — 2008-01-04T17:51:09+00:00

URL: https://externals.io/message/34393#34428 · In reply to: #34424

> 
> 
> > […]
> 
> 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!
...........................................................

---

Next page: https://externals.io/message/34393.md?page=2