Re: PHPLib and Pear merge

Hm, where we want to be tomorrow? a fast, but bad designed abstraction or a slow, but with good design and usage? i know both of the db abstractions, and i must say, the phplib abstraction has very big holes in points of needed features (e.g. transactions). ( everybody knows the problems or missed possibilities of phplib, who wrote code which is not only so basic like 'select a from b' ) the speed i think is here no point to discuss, thats a problem, which you can fix with a faster cpu oder additional tools e.g. cache. i you want it faster just write it in c or use the nativ api to each database. pear dbabstraction should be a fundamental base for easy db-unspecific using of SQL. everybody, whos using pear::db knows, that abstractions or well designed scripting source is slower than optimized one, slower, but easier to use and it increases development speed. so i would accep a much slower abstraction, if it is an well designed abstraction for every database it supports. another point is shipping pear with the main package, but thats a point which should later discussed... so keep cool and don't think in quick-hack-ways like the most of the programmers, which are coding in script language only... regards, tf PS: i want to spent my time to PEAR::DB and want to help design and code if there is really an interest making PEAR::DB really abstract, not only for mysql or postgres... -- -------------------------------------------------------------------------- http://phporacleadmin.org http://tfromm.com http://www.inubit.com "go away or I will replace You with a small PHP script!"