GeoAPI

Add setter methods to metadata interfaces

Details

  • Type: Improvement Improvement
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Won't Fix
  • Affects Version/s: 2.0
  • Fix Version/s: 2.3-M1
  • Component/s: metadata
  • Labels:
    None
  • Number of attachments :
    0

Description

Metadata may need to be mutable. For method that doesn't returns a java.util.Collection, we may need a setter method. For example in Citation:

String getTitle();
void setTitle(String);

For method that returns a java.util.Collection, only the get method is needed if the specification said that all modification in this collection must be reflected in the object owner. For example:

List getAlternateTitles();

Then, the user could uses:

getAlternateTitles().get(index);
getAlternateTitles().add(title);

etc. This is a similar approach to entrySet(), keySet() and values() methods in java.util.Map.

Issue Links

relates to

Sub-task - The sub-task of the issue GEO-94 Handling of Typed Collections

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Bug - A problem which impairs or prevents the functions of the product. GEO-51 Revisit the collection type choosen for some properties

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Hide
Permalink
Adrian Custer added a comment -

We cannot fix this bug with elegance due to our handling of Generics.

We have, in the metadata packages, collections parameterized by covariant types. For example, the Metadata interface defines the method:

Collection<? extends ApplicationSchemaInformation> getApplicationSchemaInfo()

Unfortunately, with the way Generics are handled in Java, this means that the resulting Collection is a read only data structure. While we could hack a heavy handed way around this or we could add setters for only the non-collection types but neither would be satisfactory. Alternatively we could revisit the way we have parametrized collections in the metadata interfaces.

For now, the simplest solution is to close this bug until someone has the will to tackle it seriously.

Show
Adrian Custer added a comment - We cannot fix this bug with elegance due to our handling of Generics. We have, in the metadata packages, collections parameterized by covariant types. For example, the Metadata interface defines the method: Collection<? extends ApplicationSchemaInformation> getApplicationSchemaInfo() Unfortunately, with the way Generics are handled in Java, this means that the resulting Collection is a read only data structure. While we could hack a heavy handed way around this or we could add setters for only the non-collection types but neither would be satisfactory. Alternatively we could revisit the way we have parametrized collections in the metadata interfaces. For now, the simplest solution is to close this bug until someone has the will to tackle it seriously.

People

  • Assignee:
    Unassigned
    Reporter:
    Martin Desruisseaux
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:

Time Tracking

Estimated:
1d
Original Estimate - 1 day
Remaining:
1d
Remaining Estimate - 1 day
Logged:
Not Specified
Time Spent - Not Specified