RE: RFC822 email validator.

From: Date: Mon, 20 Nov 2000 19:03:07 +0000
Subject: RE: RFC822 email validator.
References: 1  Groups: php.pear 
Request: Send a blank email to php-pear+get-458@lists.php.net to get a copy of this message
First off, my apols for taking so long to respond. Have been moving house and still don't have a net connection @ home. :(( > 1. I'd suggest making it an RFC822:: class, and having a > parseAddressList() > method inside it. Ok, have done. > Also, if you could get away with making it a > static class, that might be good. Not entirely sure what this entails, but I'm presuming that means calling methods by using rfc822::method() and not using any properties? On this basis I've created another function, which can be called statically, that creates an object, does its' thang, and then unsets the object. Kinda cheating I suppose, but does it count as static? :) > 2. While awareness of groups is a good thing, returning a different format > is a > bit awkward, since it makes this not a drop-in replacement for > imap_rfc822_parse_adrlist. Here's my suggestion: an optional flag to > parseAddressList() to turn on the group portion of the parsing. > That way you > can > guarantee compatibility by default, but get the groups if you know you're > using > this implementation. Ok, from the example script, everything now looks exactly the same, except for the order in which the object properties ($obj->mailbox, $obj->host etc) are created. But this only becomes apparent when viewed with print_r(), (I think...). > 3. Following that, if it _is_ compatible, how about checking for > the imap_* > functions, and using them if they're available? That way we provide a > only-very-small-overhead wrapper if the c-functions are available, and > transparently implement them for everyone even if they're not. Ok, done that, but an extra 700 lines of code to interpret can't be *that* small can it? > To go along with > #2, if groups functionality was requested, we'd just use the PHP > implementation > even if the imap_* functions were around. And done that too. > 4. I've been subtly calling things parseAddressList() instead of > parse_adrlist. > Studlycaps is PEAR-standard naming (at least, I _think_ we decided that), > and I > see no reason to save the few characters; use the full parseAddressList in > the > name of clarity. Ok. > Nice chunk of work! Thanks. :) Still needs converting to Pear-esque commenting style, which I'll do soon. Take care. -- Richard Heyes

Attachment: [application/octet-stream] example.php
Attachment: [application/octet-stream] Mail_Rfc822.php
« previous php.pear (#458) next »