RE: MDB2 Refactoring

> From: Hundiak, Arthur [mailto:ahundiak@ingr.com] > Sent: Thursday, December 04, 2003 10:49 PM > This is a continuation of our MDB2 and Stuff thread. > > I examined the MDB2 internals in more details. Here are a couple of > tables > which summarize the results. http://cerad.org/mdb2/mdb2.html > > As the first table shows, the MDB2_Driver_Common has about 55 methods. I > haven't worked it out precisely but the kind of slimmed down version I am > thinking about would have maybe 15 methods. So I do think that a > significant reduction is possible. > > Let's look at something else for a moment. The current implementation > uses: > > class MDB2_Driver_Specific extends MDB2_Driver_Common > > One problem with the IS_A approach is that if we do break up the > MDB2_Driver_Common class then we have to break up all the specific classes > as well and things can really start to multiply out of control. A second > problem is that users cannot extend the common class and add their own > bit's > of functionality without extending the specific classes as well. I think > this can really limit the overall usability of the class since I often > want > to add some application specific behavior. > > But suppose we change to a HAS_A approach: > class MDB2_Driver_Common > { > var $specific_driver; > ... > } > The common class takes care of redirecting calls to the specific class so > the user never knows the difference. But now we can use inheritance to > provide different levels of functionality. Ok this would be indeed a huge leap. And yes you are right this would eliminate a lot of problems as I could then make an MDB_Lite and simply extend this with the other stuff. The result would be a nice and slim MDB_Lite and a slowed down MDB2. The question is how much is the slow down and how much is the speed up. I guess I could simply make a PHP implementation of PDO in terms of the API (PEAR::DB minus all emulation code .. so no sequences, no transactions etc just query and fetch). > Do you think this is worth pursuing? If so then I'll take the next step > to > see just how practical it is do the aggregation. I know about half of the > common methods are overridden so I don't think it will be a problem. It is worth persuing. This would be something no other userland php database abstraction does. The approach MDB has taken so far is what Metabase, PEAR::DB and ADODB are doing for good reasons. However maybe the performance gained for the people that want slim is big enough and the performance hit for the others is not too big. Maybe step one would be a few benchmarks and memory analysis that show the potential improvements from the lite version. This should give us information if its worth trying out how exending the lite version affects the performance of the fat version. If you could handle those analysis and give me solid data to back up considerable (yeah a relative term) gains then I am willing to try out the idea. Regards, Lukas