Re: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
Yes, I'm aware of call() but it's very slow. Also it's not feasible to have *all* my classes extend a base class with the a call containing a throw InvalidMethodException, and what if I need to use 3rd party libraries that make use of call in some other way. __call() is a hack, that, at best, work 50% of the time. Calling methods without knowing that they exist sounds like a hack to me. How about using abstract classes or interfaces? -- Mikko Koppanen
Re: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
2007/12/31, Mikko Koppanen Calling methods without knowing that they exist sounds like a hack to me. How about using abstract classes or interfaces? If you look at, for example, python - calling methods that don't *know* exists is common practice, it's not a hack from my point of view. It's just easier to ask forgiveness then permission, to quote Hopper. I never understood the direction PHP is heading with type hinting, static binding (SPL-Types?), etc. While I don't directly oppose it I don't see any reason for it. I just thought that adding some type of ability to handle unknown method calls (without forcing *every* class to implement __call() in a specific way) would be a nice way for those of us that want to continue to use php as the dynamic, duck-typed language we learned. Maybe it will fall on deaf ears, but I thought it was worth a chance and at least propose it here on internals. Regards, Fredrik. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
On 31.12.2007 15:09, Fredrik Holmström wrote: 2007/12/31, Mikko Koppanen Calling methods without knowing that they exist sounds like a hack to me. How about using abstract classes or interfaces? If you look at, for example, python - calling methods that don't *know* exists is common practice, it's not a hack from my point of view. It's just easier to ask forgiveness then permission, to quote Hopper. I never understood the direction PHP is heading with type hinting, static binding (SPL-Types?), etc. While I don't directly oppose it I don't see any reason for it. I just thought that adding some type of ability to handle unknown method calls (without forcing *every* class to implement __call() in a specific way) There is no need to implement __call() in every class,. Just make sure their parent class implements it. Changing PHP's behavior in a backward-incompatible way that would affect everyone and *forcing everyone* to use exceptions seems to be really bad idea, especially taking into account that your problem can be easily solved without it. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
There is no need to implement __call() in every class,. Just make sure their parent class implements it. Yes, I'm well aware of that - but that doesn't really help when taking into account 3rd party libraries or places where it's not possible because you don't have control over the base class. Changing PHP's behavior in a backward-incompatible way that would affect everyone and *forcing everyone* to use exceptions seems to be really bad idea, especially taking into account that your problem can be easily solved without it. In my original post I proposed several ways that would not be backwards incompatible, and maybe I put the subject on the original message wrong - the key here isn't really exceptions but the ability to handle unknown method calls without taking the entire process down with it. Anyway this will be my last post on the subject since I don't want to spam the list and I think I've expressed all my opinions about it clearly. Regards, Fredrik. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 31 December 2007 13:48:52 Antony Dovgal wrote: Changing PHP's behavior in a backward-incompatible way that would affect everyone and *forcing everyone* to use exceptions seems to be really bad idea, especially taking into account that your problem can be easily solved without it. What exactly is the backwards compatibility break here? Without the change, the code simply dies ... if you don't catch the exception, the code simply dies ... except you get a backtrace now and can handle the exception if you want to. Regards, Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHeO5UpPjfcppEficRAng4AJ4v4G+PyT07cQTYupTgKFnOA130yQCeKWYy E2tzkWAHOmIKDc/CZw7Dtjw= =ArZH -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Re: Exceptions instead of Fatal Error when calling non existent method?
Also, it will allow PHP applications to recover more gracefully from this sort of error. A properly designed PHP application that already has global catch blocks and some 500 error pages will have this sort of error come under that same error handling process rather then give an ugly blank page. I think it will make PHP look more professional altogether. [Ahm: Also new here on the list :-)] A -Original Message- From: Stefan Walk [mailto:[EMAIL PROTECTED] Sent: 31 December 2007 13:28 On Monday 31 December 2007 13:48:52 Antony Dovgal wrote: Changing PHP's behavior in a backward-incompatible way that would affect everyone and *forcing everyone* to use exceptions seems to be really bad idea, especially taking into account that your problem can be easily solved without it. What exactly is the backwards compatibility break here? Without the change, the code simply dies ... if you don't catch the exception, the code simply dies ... except you get a backtrace now and can handle the exception if you want to. Regards, Stefan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
