RE: [PEAR-DEV] [MDB2][RFC] drastic refactoring

> From: Lorenzo Alberton [mailto:l.alberton@quipo.it] > Sent: Monday, December 15, 2003 11:46 AM > On Sat, 13 Dec 2003 16:24:35 +0100, Lukas Smith wrote: > > I could have each driver be separated into multiple inheritance > > levels which provide increasing amounts of abstraction. For each > > level of inheritance I would have a Common class which implements > > the proxy pattern. There I would implement common functionality and > > common emulation. For the common class to figure out if to proxy to > > the driver or not it would check if the method is available in the > > driver using method_exists() and if the method exist proxy, if not > > it would use some emulation if available or simply return an error > > stating that the functionality is not available. > > how is this different from previous model? > Do you mean having a onion-like layer structure? > What sort of "nesting" do you have in mind, i.e. what > methods should be moved to a deeper level? You would get an instance of MDB_Mysql but an instance of MDB_Lite, MDB_FooBar. Those instances would make an instance of a driver and proxy all of yours calls. > Would the base class have declarations of all the methods > available, no matter what level they are stored in (i.e. if the > user calls an advanced method, not part of the base class, > the base class includes at runtime the extending class which > provides the needed functionality)? > I think this way the user shouldn't worry about > including the right files, since it's done by the class itself. The base class have the necessary code to handle emulations and or missing implementations (return a pear error "implementation missing"). The user would have to choose if he wants a MDB_Lite or whatever instance. This instance cannot be "expanded" later to include more advanced functionality. Regards, Lukas