Re: PEAR Status
| From: | Sterling Hughes | Date: | Sat, 24 Jun 2000 22:48:45 +0000 |
| Subject: | Re: PEAR Status | ||
| References: | 1 2 3 | Groups: | php.pear |
| Request: | Send a blank email to php-pear+get-120@lists.php.net to get a copy of this message | ||
>
> "Hagenbuch, Chuck" wrote:
> >
> > Quoting Seth Fitzsimmons <seth@egrad2000.com>:
> >
> > > Is PEAR ready for primetime use? (In CVS versions anyway - I tried to
use
> > > it in 4.0.0 and found that a couple of keywords have yet to be
implemented.)
> > > I'd really like to use the DB modules as a replacement for phplib (as
it's
> > > part of the base distribution).
> >
> > I haven't seen much activity around it recently. Horde
(http://horde.org/) is
> > planning on using the database modules; to that end, I committed some
fixes to
> > php4 cvs that lets the pear stuff run, at least for basic operations. I
have a
> > test script that gets results from a mysql database which works, at
least - I
> > haven't done extensive testing yet.
>
> Hi Charles,
>
> have you compared the database to the PHPLib database abstractions?
> Advantages, disadvantages, performance?
>
> > Also, there are a few people working on javadoc-like parsers, which PEAR
has
> > (sort-of?) adopted as a coding standard for inline documentation. We're
also
> > busy adapting all the stuff we have in the various Horde code libraries
into
> > PEAR-style classes, complete with inline documentation.
>
> Yes, I'm working others are working on javadoc adoptions. I plan to
> present a first public beta around July the 15th.
>
> There other open issues we should work on before PEAR gets "public".
> Today only few people know that there is a package system and I don't
> mind that. Do not misunderstand me. I do welcome everybody in this list
> and I will welcome every idea. But I don't like the idea that Joe
> Doelittle ports all his code to PEAR introducing tousands of different
> ways of documentation, installation intructions or error handling
> attempts.
>
> I would like to develop some kind of standards for each of these topics
> before making PEAR "public":
>
> - inline documentation
I thought we agreed on Javadoc?
> - documentation (API, cookbook, reference, integration into php.net)
>
Use Javadoc for the module documentation as well.
Independent books and articles can cover the other stuff.
> - error handling
>
Why not through a pear error object with all necessary information:
class PEAR_ERROR
{
var $errno;
var $errstr;
var $calling_package;
var $method;
}
Then you can return from your method:
class fubar
{
function foo ($args = array())
{
if (count ($args) < 1) {
$ret = new PEAR_ERROR;
$ret->errno = WRONG_PARAM_COUNT;
$ret->errstr = "Wrong parameter count";
$ret->calling_package = "fubar";
$ret->method = "foo";
return ($ret);
}
}
}
> - how to I define what belongs to a package
http://pear.php.net/
I think we should follow Perl's example on this one.
Ie:
Mail::Sendmail -- Send an e-mail using SMTP.
or
Mail::Header -- Parse Mail headers
Packages should in other words represent an aspect of reality.
> - installation of packages
> - configuration of packages
I like the "Perl way",
Have PEAR installed in a standard directory which is in the include_path,
then the user can include packages like so:
include_once ("DB/mysql.php");
--or--
include_once("File/Find.php");
and everything will be happy.
Sterling