Re: general questions

Lukas Smith wrote: > > > In my opinion, the resultant class don't have to be a wrapper over > > anything, it should be the final "native" abstraction layer. The > > wrappers, if people want them, would be done over this class for every > > team that have and abstraction layer done and want to help their users > > the migration. > > Yes this is exactly what I wanted to say. Lets do it right and only > provide wrappers for legacy support. > > To the ADODB folks: I have not done benchmarks myself but if ADODB is > such a speedster then please help us incorporate this into this new > abstraction layer. Basically it says: "put more code in the extensions and don't complicate the OO desing". Nothing new. The difficult stuff of this statement is not to loose also maintainability and usability that's the merit of John. > Also as Manuel pointed out Metabase is OO .. so porting is not that > insanely difficult todo. Like I said we had some thing along the lines > of the get*() PEAR DB functions in metabase in no time at all. > > Also Manuels code is not crap! And I do not see any point in redoing all > of his work. If you want that then there is nobody stopping you from > writing all of Manuels features into Pear DB and then there is no need > for a "merge". Well, PEAR DB has all the features I need for my work. The rest of things are not of my personal interest and my only interest on them is only because this is a Open Source proyect and I get fun developing for it (or it isn't the reason why we are here?). There is a lot of code to read, but before starting to read all the code of all the PHP abstraction layers I prefer to take a look at solutions more wide/wise/tested like DBI. IMO the need for a "merge" has nothing to do with software, I see it like the chance of joining developers to get more minds to build greater things. Noone is willing to rewrite anything. I previously said it, the way IMHO this could get some success is writing a spec that "all" the people agrees and then cut & paste the best pieces of code from each abstraction layer. Write the goals -> write the tests -> write the API -> write the code This for sure be unequivocal for all. > So I must say my starting point will not be PEAR! I have no problem with > the PEAR the function names that PEAR uses .. so I do not see a reason > why not to use the same functions for the final version using those > names (and therefore not requiring a wrapper to make use of those > names). But Metabase is slow, why select it as the core? I have many ideas how to simplify the PEAR architecture to make it more lightweight/fast without loosing its great usability. And that's me, others will have better ideas. What you are wanting to do is to rename Metabase functions to be more similar to PEAR DB? It's the same statement you said before: Stig's code is not crap! Why not just do a better API for Metabase and forget the merge? ;) __IMHO__ if you want (I also want) to get succes don't came here in 4 days saying: "Here I present you the new API of Metabase, take it and use it". And I repeat, this is my only opinion. > I will not port some of the stuff that is part of the PEAR DB fetch*() > stuff. Those features basically allow a programmer to write bad SQL > queries and then do the real sorting/searching inside of PHP. But anyone > else is obviously welcome to do this. Huh? I you don't port fetch* you won't be able to retrieve rows :) You are refering to other thing no? > I would violently oppose those functions becoming part of the work > component though. 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. Same with the encryption stuff that > binarycloud did. Same with stuff like working with Syntax difference > between RDBMS for SQL functions (SUBSTR() - SUBSRTING()). > Etc etc To provide an abstracted SQL dialect is part of the goals (even if it is pluggable)? Tomas V.V.Cox