[
https://issues.apache.org/jira/browse/MAILBOX-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13256455#comment-13256455
]
Ioan Eugen Stan commented on MAILBOX-175:
-----------------------------------------
Hi Gazda,
Nice.Overall +1. See my comments:
1. Please do, I think you can set them to final and remove setters. I don't
know how things will impact the existing code but we should fix things if they
are broken.
2. From some time now I prefer to use guava's Preconditions. I find it makes
the code clear and small. Guava also has some nice way of generating good
equals and hashcode, etc.
We should fail fast if something wrong.
3. Agree, please consider guava Preconditions again.
3.4 Don't know
As a final note I like when I can count on certain things staying the same no
matter what.
> Make the contract of MailboxPath explicit and documented.
> ---------------------------------------------------------
>
> Key: MAILBOX-175
> URL: https://issues.apache.org/jira/browse/MAILBOX-175
> Project: James Mailbox
> Issue Type: Sub-task
> Components: api
> Reporter: Jochen Gazda
> Assignee: Jochen Gazda
>
> Make the contract of org.apache.james.mailbox.model.MailboxPath explicit and
> documented.
> Points to consider:
> (1) Make all attributes immutable - can be done quite easily, no discussion
> expected.
> (2) Null values should be forbidden for at least for name and namespace
> attributes - NullPointerException will be thrown from constructors. A lot of
> client code uses e.g. getName().length(). Clients should be responsible for
> the proper values when creating new instances of MailboxPath.
> (3) Consider adding a delimiter field. Currently delimiter is implicitly
> present in the name value anyway. It would allow:
> (3.1) removing the delimiter parameter from getHierarchyLevels()
> (3.2) adding relativePath(relativeName) method (which is currently done by
> concatenating path segments with bona fide default delimiter in the client
> code).
> (3.3) name attribute could guarrantee that it does not start with delimiter
> (which is sometimes checked in the client code now). For names starting with
> delimiter, either
> (3.3.a) constructors should throw IllegalStateException or
> (3.3.b) the name attribute would be rewritten silently - should perhaps
> be prefered, because of the existing client code.
> (3.4) Currently, there is no delimiter escaping/unescaping (e.g. in parse()
> or getHierarchyLevels()). Should there be any?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
