Re: general questions
| From: | Stig S. Bakken | 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