Re: [Zend Engine 2] Re: [PHP-DEV] Re: [Zend Engine 2] Type hints revisited [IllegalArgumentException instead of E_ERROR]

On Fri, 28 Mar 2003, Andi Gutmans wrote: > I guess I'm completely missing your point. Why will PEAR scripts using > type hints be incompatible with a larger application framework? You > forget that passing the wrong type to a PEAR function *is* an error. > How come you suddenly don't want any errors? Do you want people to be > able to do as much damage as they want? A writes an application framework as part of their commercial product. B writes a generic class and publishes it in PEAR (using type hints). C purchases the app from A and extends it using the class from B. There is nothing that A can do to prevent or catch the E_ERROR from the typehint. We can use function_exists() to prevent errors when calling functions, but there is no is_parameter_of_correct_type() function to guard against this problem. The reflection API will help, but it still makes things suck more than is strictly needed. > You're supposed to use it to handle run-time errors but not base your > application's logic on throwing exceptions, i.e., on purpose not check > what types you are sending to a function because you prefer to handle > the exception. In a long lived environment this will be a problem > because you'll end up having scripts with a large amount of > exceptions. A's code knows nothing about B or C's code; its intention is just to catch all errors, report the problem and try to keep running. If exceptions leak memory, that implies that their implementation is flawed; there should be no reason that they leak (based on my understanding of the ZE, which is not quite so good as yours ;-) its just an opcode executed by the engine; any locally scoped zvals should be dtor'ed when the stack unwinds. > I'm sorry to hear that you consider the OOP support in PHP 5 to be > half assed. Personally I think people like you who are trying to > pervert PHP into Java are just going to cause damage to PHP. The > current tree has very good functionality which will be an incredibly > big step forward for people wanting to develop OOP with PHP. I don't like Java; my opinions on this matter have nothing to do with Java. I've some plans for some nice big applications that I can *almost* write using PHP. The limiting factor has primarily been the not-so-good OOP support in PHP4; things have been looking good to go with PHP5, but the number of the new OOP features that raise E_ERRORS is making it difficult to write code that can intelligently deal with the errors. I'm not neccessarily talking about long-lived applications, but applications where there is a large amount of complex shutdown/recovery code to execute in the face of an error. > > >What is *so* wrong with throwing an exception from type hints? It > >will still cause the script to bail out if the exception is not > >caught (which will keep you and the novice programmers happy), and it > >allows more advanced programmers to apply PHP in more and more > >advanced ways. > > It's not *so* wrong but I think you guys are exaggerating with the > tragic "this is terrible" sound you have about each little relatively > non-signifcant feature which will just end up bloating PHP, make it > more complex, and in the end will make it into Java. I don't want to > abandon the existing user base. I don't see how having type-hints throw exceptions is abandoning an existing userbase; it's a new feature anyway. > Again, why work hard if Java already exists? Because Java sucks and because PHP can be so much better :) One of the reasons that I like PHP is that it is loose enough that you can focus on writing code rather than battling with over the top syntax/type restrictions (Java), or with the tedious string manipulation (C). I *like* PHP; it tries to keep running in the face of non-fatal errors. I don't like E_ERRORS when there is no real reason to bail out. As I've already said, non of the other PHP functions trigger E_ERROR when the parameters are incorrect; it's just an E_WARNING and a NULL value return. Implementing these new OOP features and having them E_ERROR is tremendously unhelpful (the PPP stuff also suffers from the same problem). I don't want PHP to be a Java clone any more than you do, but why code these great new features with such limitations from the start? Surely this is just a one-line change anyway (just substitute zend_error for the exception raising macro)? --Wez.