On Fri, 28 Mar 2003, Andi Gutmans wrote:
> The point of type-hints is to be able to catch errors in your code > quickly and not having to write checks, the point isn't to catch > problems in your code at run-time. And as I said before, if it doesn't > suite you then don't use type-hints and use instanceof like you would > have done 2 weeks ago. It's not a disaster so don't make it sound > like one. So much has changed in the past two weeks? If you need to > catch errors because you are writing something generic such as SOAP > (which most of the PHP community doesn't do) then go ahead and do the > instanceof's you need to do.
The point is that the SOAP (or whatever) library will be interfacing with code written by others. If those other people use type hints and it blows up with an E_ERROR, we don't have a nice way to handle this error and continue serving.
If those people decided to use type hints then they are getting what they expected, no?
This *is* a disaster, because we are introducing a feature that appears to be quite nice at first glance, but causes portability issues with peoples scripts; for instance; PEAR scripts that use type hints will immediately be incompatible with a larger application framework. Therefore, PEAR should not use type hints if it wants to remain portable.
The same applies to all script libraries.
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?
> Exceptions have a potential of leaking memory. I have mentioned in the > past that I wouldn't base my applications logic on exceptions but only > use it in error conditions to clean-up and/or give a nice message. You > are talking about using it as part of your application logic.
What is the point of structured exception handling if you are not supposed to use it to code the logic to handle run time errors?
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.
> You are convincing me more and more not to throw an exception with > type hints.
And you are convincing me more and more that the OOP and error handling model in PHP5 will continue to be half-assed for a long time to come :/
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.
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. Again, why work hard if Java already exists?
Andi
-- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
