NYCPHP Meetup

[Adam Maccabee Trachtenberg]

On Mon, 16 Feb 2004, jon baer wrote:

> 1. first, im really into the fact that you now can declare the type of
> objects passed into function *but* why only custom classes?  i know the
> beauty of loose type is nice but when reading code it would be nice to see
> what i should be expecting + drop the redundancy to need to check variables
> over + over:

I believe this logic is that passing an object of the wrong type is
usually "clearly wrong," while PHP's ability to automatically coerce
built-in variable types makes it less likely that passing in a string
instead of an integer is incorrect.

For instance, what should PHP do if you pass in a "string" that can be
coerced into an integer? This'll happen if your data comes from a form
or a database.

> 2. will there be a complete generic exception handler built-in or is there
> one - did i miss it?  for example this type of simple bad connection error:
>
> try {
>     mysql_connect("blah","blah","blah");
> } catch (Exception $e) {
>     echo $e->getMessage();
> }
>
> is the TCF stuff mainly for new classes being built?  would it not be
> helpful to have something like this built-in for older stuff (PHP4/5) or
> something in the php.ini:

Exceptions only work for extensions (classes) that throw them. Legacy
extensions will not throw exceptions.

Right now, exception support on a language level (Zend Engine) may be
almost fully baked, but exception usage is not. Very few extensions
have been updated to take advantage of this feature. I don't think
you'll really see wide-spread exception usage in core extensions until
PHP 5.1.

Also, there's currently a debate on the internals list if all
exceptions should (a) be required to extend a base Exceptions class
(b) be any damn class they choose to be (c) should be implemented
using a Throwable interface. So, it's still being hashed out exactly
how exceptions should work.

This is just one example of PHP 5 being somewhat schizophrenic. On one
hand, there's a desire to add more advanced OO features and other
programming nicities. On the other hand, PHP wants to remain an
easy-to-use procedural language.

It's tough to create a balance where people who are really into OO can
go object-wild while "regular programmers" can just program and not
worry about all the extra baggage they don't care about.

-adam

-- 
adam at trachtenberg.com
author of o'reilly's php cookbook
avoid the holiday rush, buy your copy today!