Re: Re: [sqlite] PHP5 && SQLite3

Andi Gutmans wrote:

At 01:29 PM 10/20/2004 +0100, Wez Furlong wrote:

PDO is something that quite a few of us want to see as the recommended database API for PHP 5.1. We haven't laid any definite plans for the 5.1 feature list yet (it's probably a good time for us to start thinking about that here on internals@) so there is not yet an official line on PDO or SQLite 3.

Hi Wez, I definitely think it's starting to become time to talk about what's going to be in PHP 5.1. I see the main features I would like to see in 5.1 as: a) PDO support for most popular DBs. Maybe you can give a status report of where PDO is today and how much work it still requires? If it requires a lot of work maybe more people can join the effort. Also is there an online phpDoc of each DB API one can look at? I've looked at the source code and at the functionality and it's pretty good but I'll definitely try and look deeper as we get closer to 5.1. b) New VM architecture, some other core engine changes which have happened since 5.0.x. c) Polish some left overs in the OO model from 5.0.x, mainly the access modifiers (if/when they are allowed to be used). For example, in interfaces they shouldn't be used. Probably some error handling and bug reports which still require attention. d) Finalize the few tiny new features request on the language level from 5.1. e) I agree with Derick, internationalization support is a good one

f) if at all possible, It would be very good if the exception signature could be modified to accept another exception object as a third parameter. Why? try {

    // blah

} catch (SubException $e) {

    throw new ParentException('message', CODE, $e);

} ..... class ParentException extends Exception {

    function __toString()
    {
        $current = parent::__toString();
        if ($arr = $this->getCauses()) {
            $current .= "\nThis exception caused by:\n"
            foreach ($arr as $e) {
                $current .= $e->__toString();
            }
        }
        return $current;
    }

} This will allow chaining of exceptions, as they can be designed to do already, but in a simple, standardized way. It would not need to affect uncaught exceptions, but __toString() could take advantage of getCauses() to spit out this information. see pear-core/PEAR/Exception.php for userland example. I'd like to remove as much logic from this class as humanly possible, and concentrate its efforts on display of information only. If this sounds like a worthy effort, should I open a feature request? Thanks, Greg