Re: Advice on design issues (long)...

From: Date: Mon, 25 Mar 2002 17:32:26 +0000
Subject: Re: Advice on design issues (long)...
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-5105@lists.php.net to get a copy of this message
"Lukas Smith" <smith@dybnet.de> wrote in message news:002201c1d41f$0b976370$4d00a8c0@vandal... > I think this is a major source of uglyness of php having so different > interfaces to all the various RDBMS. Most of the "db abstraction" > packages are more about cleaning this uglyness than abstraction. that seems to be true. however, to be fair, it takes a _lot_ of work and thought to do both. > I have not checked into dbx was much was I wanted (or should), but I > have heard that he is also moving forward. > he _is_ moving forward. i think sybase_ct support was recently added. the same limitations also apply to dbx, since it builds directly on the current extensions. but its a heck of a lot faster than userland code. > Yeah you gotta start somewhere ... MDB currently also only supports > MySQL > The other advantage is that you then have a zillion people that can > easily test your stuff. So doing MySQL makes sense (as long as you keep > the other DBs in the back of your head) the next driver on my agenda is Interbase, since it supports all of the features the extension is currently scheduled to support. this should be a good test of the design. > > I wonder if it would be possible to somehow allow people to "extend" > object that are provided by a C extension in userland. That would be > really cool. (I don't know enough about php extensions to really tell .. > but maybe that would be a nice feature request for php5?) you can actually do that now. an object in an extension is on par with a user-space object as far as inheritance is concerned. however im excited about PHP5 because of the enhanced object overloading features. this will allow us to have the "base" abstraction support, as well as providing for driver specific functionality. this way you can write portable applications, but be able to add DB specific functionality if the situation warrants. l0t3k

« previous php.pear.dev (#5105) next »