Re: general questions

From: Date: Tue, 04 Dec 2001 13:11:05 +0000
Subject: Re: general questions
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-3351@lists.php.net to get a copy of this message
Lukas Smith wrote: > > Hi, > > as I stated in another thread we are currently investigating making the > metabase API abit more OO style. > > Since several people stated their interest in making metabase part of > PEAR (I also think this is a good idea) we would want to make this > metabase API switch in such a way to be PEAR complaint. > > I must admit so far I have not used any PEAR packages, so I have a > couple little questions. > > I still don't quite get the usage of "::" .. > As far as I understand this is for so called static functions and to > generate a new namespace ... > > So far so good > But why do stuff like DB::connect ? > Why not put stuff like that in a constructor? > > Then another question: > The package obviously has to be named something ... the current DB > package is called "DB" .. what would this "other" package be called? > > Since everything has its own namespace what is the prefixing for? > As long as the package name is unique ... ? > > Somehow I think the manual has not really explained to me why things are > like they are :-) > > I hope I am not making too much of a fool of myself with these > questions. The fact that DB::connect is a factory is a design issue, I wanted to keep the options open for another object architecture, but keeping the same API. Today PEAR DB has a separate class that for every database driver, and an instance of this class is what DB::connect returns. However, I don't want to bind PEAR DB to this design forever, one day we might decide to return for example a DB_Connection object instead, and use aggregate objects for everything database-specific. If you put DB::connect's logic inside the driver class constructor, you lose this opportunity. As a side note, most people seem to think that PEAR DB has the best API while Metabase the best set of features. I agree, and this is why I focused on a good and flexible API for PEAR DB. The fact that we're discussing the merging of PEAR DB and Metabase today means that this wasn't such a bad decision :-) - Stig

« previous php.pear.dev (#3351) next »