GeoAPI

Consider making CodeList.valueOf(String) to ignore whitespaces

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Fixed
  • Affects Version/s: 2.3-M1
  • Fix Version/s: 2.3-M3
  • Component/s: util
  • Labels:
    None
  • Number of attachments :
    1

Description

The method CodeList.valueOf(String) first searchs for an existing CodeList matching the given string before to create a new one. The current implementation is case-insensitive, so if a user asks for a "utf8" code list while the existing one is named "UTF8", the existing code list is returned.

We propose to additionaly ignore whitespaces. So if the user asks for "UTF 8", it is recognized as well as the existing "UTF8" code list. Currently it is not. Likewise if the user asks for "document hardcopy" in PresentationForm, it will be recognized as "documentHardcopy".

Note: it would be possible to extend the proposal for ignoring the "_" character as well, so in the above example "document hardcopy" would also be recognized as the same as "DOCUMENT_HARDCOPY", which is the same code list. The current proposal is limited to whitespaces because it is less at risk of being disruptive, given that whitespaces are normally never part of identifiers.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Martin Desruisseaux added a comment -

Attached the proposed implementation as a patch file.

Show
Martin Desruisseaux added a comment - Attached the proposed implementation as a patch file.
Hide
Permalink
Martin Desruisseaux added a comment -

According discussion on the mailing list, the opposite proposal (keep valueOf strict by removing its case-insensitive aspect) seems to have the preference. In such case, ignoring whitespaces and case would be left on implementor side. An open question is whatever we need to provide a hook in GeoAPI or not. For example a hook could be:

<C extends CodeList> C valueOf(Class<C> type, String identifier, Comparator<String,String> cmp);

i.e. compared to the current signature, a Comparator argument would be added.

Show
Martin Desruisseaux added a comment - According discussion on the mailing list, the opposite proposal (keep valueOf strict by removing its case-insensitive aspect) seems to have the preference. In such case, ignoring whitespaces and case would be left on implementor side. An open question is whatever we need to provide a hook in GeoAPI or not. For example a hook could be: 
<C extends CodeList> C valueOf(Class<C> type, String identifier, Comparator<String,String> cmp);
i.e. compared to the current signature, a Comparator argument would be added.
Hide
Permalink
Martin Desruisseaux added a comment -

It may be better to define a Matcher inner interface with a boolean match(CodeList code, String name) method instead.

Show
Martin Desruisseaux added a comment - It may be better to define a Matcher inner interface with a boolean match(CodeList code, String name) method instead.
Hide
Permalink
Martin Desruisseaux added a comment -

Commited a Filter inner interface with an accept(CodeList<?>) method as of revision 1443.
New method: CodeList.valueOf(Class, Filter).
Deprecated method: CodeList.matches(String) since it applies arbitrary rules (ignoring case, etc.).

Show
Martin Desruisseaux added a comment - Commited a Filter inner interface with an accept(CodeList<?>) method as of revision 1443. New method: CodeList.valueOf(Class, Filter). Deprecated method: CodeList.matches(String) since it applies arbitrary rules (ignoring case, etc.).

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.