headers
PEPr | 1 Feb 2004 11:51
Picon

[PEPr] Comment on Mail::Imap


Bertrand Mansion (http://pear.php.net/user/mansion) has commented on the proposal for Mail::Imap.

Comment:

I don't like the class with your recent additions related to output (called "Bells and Whistles" in your
comments). Those methods are View related and output html. They don't belong here and they just make the
class more bloated.

Same thing for the forum stuff. Just get rid of it, if people want to have this feature, all they need is the raw
mail body and a static function to parse that content in the format they want. Really this just adds bloat to
a class that needs to be as light as possible.

Also, I don't see the point to call your methods imapSomething. Just get rid of the imap prefix and we might be
able to later have a Mail_POP3 class with the same API.

And again, you have instance vars called ccPersonal etc., which might not be set. Are you going to try to
match every possible header lines to instance vars ? That's the bad way. Just have a header instance var
(array) and fill it with clean header values. Then add a few accessor methods for common header content
that needs cleanup (ie. getTo(), getFrom(), getSubject()...).

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=17

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
(Continue reading)

Permalink | Reply | 0 comments |
headers
PEPr | 1 Feb 2004 15:52
Picon

[PEPr] Proposal for Configuration::Config_Registry


Laurent Laville (http://pear.php.net/user/farell) proposes the new package Configuration::Config_Registry.

You can find more detailed information here:
 http://pear.php.net/pepr/pepr-proposal-show.php?id=18

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Daniel Convissor | 1 Feb 2004 19:41
Favicon
Gravatar

Re: [Fwd: Re: PEAR framework changes for PHP5]

On Sun, Feb 01, 2004 at 12:12:26AM +0100, Stefan Neufeind wrote:

> Only, and only(!), if the class is not yet 
> present you may include 'Data/Bar.php' in this case. So big deal, 
> easy to implement, and extendable - in my eyes.

Easy, yes.  But it adds a lot of unnecessary if statements.

Either you use PEAR or you don't.  If you like some PEAR features and want
to use them in your own special customizations, great, just go ahead and
copy the files to the location you want and make the modifications you
desire and you're good to go.

--Dan

-- 
 T H E   A N A L Y S I S   A N D   S O L U T I O N S   C O M P A N Y
            data intensive web and database programming
                http://www.AnalysisAndSolutions.com/
 4015 7th Ave #4, Brooklyn NY 11232  v: 718-854-0335 f: 718-854-0409

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 3 comments |
headers
PEPr | 1 Feb 2004 20:03
Picon

[PEPr] Comment on Configuration::Config_Registry


Chuck Hagenbuch (http://pear.php.net/user/chagenbu) has commented on the proposal for Configuration::Config_Registry.

Comment:

I'm completely neutral to this being in PEAR, since it duplicates Horde's existing code. However, given
the extent to which it copies a large number of ideas from a core Horde package, it'd be nice to have Horde
credited more directly by the package.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=18

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Chuck Hagenbuch | 1 Feb 2004 20:13
Favicon
Gravatar

Re: [Fwd: Re: PEAR framework changes for PHP5]

Quoting Daniel Convissor <danielc <at> analysisandsolutions.com>:

> Easy, yes.  But it adds a lot of unnecessary if statements.
>
> Either you use PEAR or you don't.  If you like some PEAR features and want
> to use them in your own special customizations, great, just go ahead and
> copy the files to the location you want and make the modifications you
> desire and you're good to go.

A lot? No, one. Unnecessary? Only if you don't want your package to be able to
be extended by custom drivers - which may not make sense as part of the general
package sometimes. I think the way the Log packages implements things is a
perfectly reasonable way to allow this, and that having it is more than worth
the single if. The all-or-nothing attitude is not going to make PEAR more
useful as a framework. If you want all-or-nothing, use a whole app suite (like
Horde <g> - but even Horde lets you add custom drivers easily, or glue a
non-Horde application into the system with a few lines of code).

Also, checking class_exists() after doing the  <at> include_once is simply good
practice, since it lets you avoid errors if there's a parse error or some other
reason that the class didn't actually get defined.

-chuck

--
Charles Hagenbuch, <chuck <at> horde.org>
"Here, I brought some cole slaw. It's made from peeeooople! Just kidding."

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pierre-Alain Joye | 1 Feb 2004 20:18

Re: [Fwd: Re: PEAR framework changes for PHP5]

On Sun,  1 Feb 2004 14:13:36 -0500
Chuck Hagenbuch <chuck <at> horde.org> wrote:

> A lot? No, one. Unnecessary? Only if you don't want your package to be
...
> a non-Horde application into the system with a few lines of code).

Agreed, however (to be precised) it is up to the package to do that. As
far I do not see require_once AFOOBAR_CONSTAN.'foo.php'; at the top of
each file I'm happy ;)

> Also, checking class_exists() after doing the  <at> include_once is simply
> good practice, since it lets you avoid errors if there's a parse error
> or some other reason that the class didn't actually get defined.

Yes, even thought that if you do not need an error handler here (in the
sense to manage a non existing class or file) you may use
require(_once) which will stop the execution.

pierre

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
Christian Hammers | 1 Feb 2004 20:36
Picon
Favicon

Re: Idea for an OOP frontend for Console/Getopt.php

Hello

On Thu, Jan 29, 2004 at 12:35:00PM -0500, Greg Beaver wrote:
> I could see a new method in Console_Getopt that would take 3 arguments, 
> the long, short options and an object.  Also, any command-line that is 
> passed more than once could simply be added to an array
> 
> if (isset($obj->key)) {
>     if (!is_array($obj->key)) {
>         $obj->key = array($obj->key);
>     }
>     $obj->key[] = $value;
> }
> 
> However, I see no reason for using an object as an array - this would 
> just slow things down.  After all, what's the difference between 
> $obj['key'] and $obj->key?  2 characters?  You still have to do isset()

Sadly it's not that simple. Currently you get back something like this:
	array(3) {
	  [0]=>
	  array(2) {
	    [0]=>
	    string(5) "--key"
	    [1]=>
	    string(1) "4"
	  }
	  [1]=>
	  array(2) {
	    [0]=>
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pierre-Alain Joye | 1 Feb 2004 20:40

Re: Re: Idea for an OOP frontend for Console/Getopt.php

On Sun, 1 Feb 2004 20:36:56 +0100
Christian Hammers <ch <at> lathspell.de> wrote:

> So to see if "--key" was given, you would have to do a foreach loop
> and check for [0]=="--key" (or do I miss a proper array function?).

Dunno how you work with arguments but I always have toloop through them
and do the appropriate actions. And note that is how works most of
getopt functions all around.

pierre

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
PEPr | 1 Feb 2004 21:54
Picon

[PEPr] XML::XML_Simple deleted


Stephan Schmidt (http://pear.php.net/user/schst) has deleted the proposal for XML::XML_Simple.

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 0 comments |
headers
PEPr | 1 Feb 2004 22:48
Picon

[PEPr] Comment on Configuration::Config_Registry


Laurent Laville (http://pear.php.net/user/farell) has commented on the proposal for Configuration::Config_Registry.

Comment:

I'm totally agree with Chuck. As i took idea from Horde project, credits should be added. 

I've always thought that good idea or source code should be re-used than making it again and again.

Just my point of view; hope you understand. And don't let away a good contribution.

Proposal information:
http://pear.php.net/pepr/pepr-proposal-show.php?id=18

-- 
Sent by PEPr, the automatic proposal system at http://pear.php.net

--

-- 
PEAR Development Mailing List (http://pear.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Permalink | Reply | 15 comments |

Gmane