RE: [PEAR-DEV] general questions

Aehm ... "If Lukas Smith will really create this new wrapper and later 'violently oppose' contributions like the fetch*() family of methods, then we have a problem." Please do not quote out of context like this My original statement was: "I would violently oppose those functions becoming part of the work component though." This is a very different statement when compared to how you quoted me. Then again I think there is a little typo (eventhough my lastname is Smith I am a German native and German is also my mother tongue): "work" should have been "core". But I do believe my next sentence made my true intentions clear: "We should create a nice way to load this added functionality when need. Same with some of the create/alter related functions that metabase offers." So please read peoples statements with a less "he is out to kill me" attitude. Thanks Also do not worry: I don't know your address so you have few to fear from my 'violent opposition' :-) Finally I never said I will do the entire thing myself. I will follow through with my original plan (that I have talked to Manuel about before this thing popped up) to make a more OO-style interface to Metabase. Manuel throw my name on the table in the pear dev list and informed me of this. Since then I have said that I will use the PEAR API and I also said that I do not see any reason why not to use the PEAR DB function names. I also did state that I want this to be part of PEAR and I think whatever will be included in PEAR will be the thing that will matter to the PHP world and not "Lukas DB." So if people want stuff in there then they can stick in there. I also said that I do not like the fetch*() functions because I don't think there is a need for them next to the get*() functions. I don't think people should skip rows because they should order the rows how they want them and limit the result set beforehand. This port, merge whatever will be a bit of work to complete so I hope you understand that I will skip on stuff that I feel is sort of redundant. One thing that may also have caused confusion which I want to correct here is my assumption that fetch*() also has a feature to reorder SQL result sets. This was a misunderstanding on my part that I recently discovered because I got confused by the name of "DB_FETCHMODE_ORDERED" and I was quickly looking over various DB abstraction layer APIs. I apologize for any confusion. Best regards, Lukas Smith smith@dybnet.de _______________________________ DybNet Internet Solutions GbR Alt Moabit 89 10559 Berlin Tel. : +49 30 83 22 50 00 Fax : +49 30 83 22 50 07 www.dybnet.de info@dybnet.de _______________________________