[
https://issues.apache.org/jira/browse/NET-333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009636#comment-13009636
]
Bogdan Drozdowski commented on NET-333:
---------------------------------------
Why not an enum? The reason I had was simple: although enums provide type
safety (which is very good), I believe enums can't be subclassed nor they can
derive from other classes, so if we have "enum IMAPCommand", we can't have a
class, say "public class IMAPSCommand extends IMAPCommand" or "public enum
IMAPSCommand extends IMAPCommand". This means that additional commands must
either be inserted into the base class, say IMAPCommand (now what if you're
using just the binary release?), or inserted into the class that uses them
(like I did in the AuthenticatingSMTPClient or ExtendedPOP3Client), or have
their own class, completely unrelated to the base class. The first is possible
only if you have the source and either build it yourself or wait for your patch
to be applied, because it's impossible to subclass the base class currently.
The second and third solutions, on the other hand, spread the set of commands
among many classes. That's why I did it this way. With this in mind, the
"final" keyword on the IMAPReply class declaration is an error, I copied too
much from other classes. If these classes aren't made enum/final, users can
subclass them without the source code and inherit all the commands/replies
automatically, so they can, for example, subclass *Client classes and have them
use or produce their own subclasses of *Command and *Reply.
I'm not currently subscribed to the mailing list, I'll browse the archives to
check the volume and perhaps I'll join you. Yes, some code is plainly copied
between the classes, but the details vary. Every clas has a __getReply() but,
for example, the line continuation algorithm varies. This could be made
abstract, but what if we want just a SocketClient? We couldn't instantiate it
now. Currently (in the classes I'm interested in: IMAP, POP3, SMTP, FTP) I can
see that add/removeProtocolCommandListener could be immediately pushed up
either to SocketClient or to something new between the SocketClient class and
the protocol classes (not the *Client classes).
Did you verify that POP3SClient and SMTPSClient work for you? I used them and
they worked fine for me, but the IMAPSClient shows that they shouldn't (because
they don't replace _reader and _writer from the SSLSocket) and I'm puzzled.
> would you provide a class used for imap protocol?
> -------------------------------------------------
>
> Key: NET-333
> URL: https://issues.apache.org/jira/browse/NET-333
> Project: Commons Net
> Issue Type: Improvement
> Reporter: iceviewer
> Attachments: IMAP.zip
>
>
> would you provide a class used for imap protocol?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
