You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Sebb (JIRA)" <ji...@apache.org> on 2011/03/27 17:17:05 UTC
[jira] [Created] (NET-392) Use enum for IMAPCommand
Use enum for IMAPCommand
------------------------
Key: NET-392
URL: https://issues.apache.org/jira/browse/NET-392
Project: Commons Net
Issue Type: Sub-task
Reporter: Sebb
As mentioned in the main issue, I think it would be better to use enums instead of int for the IMAP commands.
I agree that enums cannot be extended, but as far as I can tell, it won't be easy to extend the existing method either.
One can subclass IMAPCommand, but this won't be simple:
- how to prevent duplication of numbers if the parent class is later extended?
- how can the method IMAP.sendCommand(int command, String args) know where to pick up the new entries?
At present it references the static method IMAPCommand.getCommand(); it would probably be necessary to change this to use an instance of IMAPCommand and an instance method, which could then be overridden.
Seems to me that allowing extension via subclassing will make the code more complicated and fragile.
If new IMAP commands are added, the user can still pass in a String until such time as the code is updated.
Whereas if the code is changed to use enums, these can be used to provide additional validation - e.g. the enums could have an attribute that defines how many parameters are needed; this could then be checked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-392) Use enum for IMAPCommand
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb updated NET-392:
---------------------
Fix Version/s: 3.0
> Use enum for IMAPCommand
> ------------------------
>
> Key: NET-392
> URL: https://issues.apache.org/jira/browse/NET-392
> Project: Commons Net
> Issue Type: Sub-task
> Reporter: Sebb
> Fix For: 3.0
>
>
> As mentioned in the main issue, I think it would be better to use enums instead of int for the IMAP commands.
> I agree that enums cannot be extended, but as far as I can tell, it won't be easy to extend the existing method either.
> One can subclass IMAPCommand, but this won't be simple:
> - how to prevent duplication of numbers if the parent class is later extended?
> - how can the method IMAP.sendCommand(int command, String args) know where to pick up the new entries?
> At present it references the static method IMAPCommand.getCommand(); it would probably be necessary to change this to use an instance of IMAPCommand and an instance method, which could then be overridden.
> Seems to me that allowing extension via subclassing will make the code more complicated and fragile.
> If new IMAP commands are added, the user can still pass in a String until such time as the code is updated.
> Whereas if the code is changed to use enums, these can be used to provide additional validation - e.g. the enums could have an attribute that defines how many parameters are needed; this could then be checked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-392) Use enum for IMAPCommand
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb resolved NET-392.
----------------------
Resolution: Fixed
> Use enum for IMAPCommand
> ------------------------
>
> Key: NET-392
> URL: https://issues.apache.org/jira/browse/NET-392
> Project: Commons Net
> Issue Type: Sub-task
> Reporter: Sebb
>
> As mentioned in the main issue, I think it would be better to use enums instead of int for the IMAP commands.
> I agree that enums cannot be extended, but as far as I can tell, it won't be easy to extend the existing method either.
> One can subclass IMAPCommand, but this won't be simple:
> - how to prevent duplication of numbers if the parent class is later extended?
> - how can the method IMAP.sendCommand(int command, String args) know where to pick up the new entries?
> At present it references the static method IMAPCommand.getCommand(); it would probably be necessary to change this to use an instance of IMAPCommand and an instance method, which could then be overridden.
> Seems to me that allowing extension via subclassing will make the code more complicated and fragile.
> If new IMAP commands are added, the user can still pass in a String until such time as the code is updated.
> Whereas if the code is changed to use enums, these can be used to provide additional validation - e.g. the enums could have an attribute that defines how many parameters are needed; this could then be checked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (NET-392) Use enum for IMAPCommand
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-392?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb closed NET-392.
--------------------
> Use enum for IMAPCommand
> ------------------------
>
> Key: NET-392
> URL: https://issues.apache.org/jira/browse/NET-392
> Project: Commons Net
> Issue Type: Sub-task
> Reporter: Sebb
> Fix For: 3.0
>
>
> As mentioned in the main issue, I think it would be better to use enums instead of int for the IMAP commands.
> I agree that enums cannot be extended, but as far as I can tell, it won't be easy to extend the existing method either.
> One can subclass IMAPCommand, but this won't be simple:
> - how to prevent duplication of numbers if the parent class is later extended?
> - how can the method IMAP.sendCommand(int command, String args) know where to pick up the new entries?
> At present it references the static method IMAPCommand.getCommand(); it would probably be necessary to change this to use an instance of IMAPCommand and an instance method, which could then be overridden.
> Seems to me that allowing extension via subclassing will make the code more complicated and fragile.
> If new IMAP commands are added, the user can still pass in a String until such time as the code is updated.
> Whereas if the code is changed to use enums, these can be used to provide additional validation - e.g. the enums could have an attribute that defines how many parameters are needed; this could then be checked.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira