Re: Imap Backend Propsal

Bertrand, >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... --Ok point taken. I still would like to implement viewer related helper functions in some form, if not directly in this class then in another. The idea behind the class is to simplify common tasks, and beleive it or not converting hyperlinks is a common task.. it is something everyone writes at one point or another, needlessly reperfecting something that's been done thousands of times. I also find the forum code feature very helpful and I don't think very many people think of including that in email applications. I do see your point in why that portion of the process should be excluded from this class but I feel it is something that should be done, perhaps in a companion class. You could have also mentioned this when I first proposed the idea of including those features in my class on the PEAR-DEV mailing list. : ) >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. --This class mostly just wraps IMAP functions, thus I thought it helpful to name the functions after what they were wrapping. But again, point taken. Abstraction is always good! >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()...). I have taken your suggestions into consideration and consolidated all address related header information into the getXxx methods, removed flag references, since they can be pulled directly from the object created by imap_headerinfo, and I've miminized header-related member variables to just a handful. I really don't see the need for a method like getSubject(), since setHeaders (renamed) creates an object that contains that information already and also transfers that information to a smaller, easier to reference member variable. Though I would still like to seek a method which places all of this information in member variables, I feel that creates a non-obfuscated object, as well as logically following the structure provided by the functions it is seeking to work with, not to mention calling getXxx methods requires that extra step of making a function call for each of that information whereas setHeaders is called but once and the information is available, information is use d the unsetHeaders is called. If the information is not present in the headers, then the variable is empty, why is that bad? imap_headerinfo is pretty black and white as far as what header information it provides. I don't understand why member variable creation is so taboo here. Best Regards, Richard York