Closed HarelM closed 6 years ago
It makes sense to give, e.g., GpxRoute[]
to the consumer from Read
, since we can always guarantee that it'll be an array, which gives the consumer maximum flexibility for what they can do with it right away, at no performance penalty. So yeah, it totally makes sense to have a Read
kind of method that gives back a single object that encapsulates all the top-level gpx
element content.
On the other hand, it doesn't make quite as much sense for Write
to accept the same. The provider might want to pass in any number of different sequence types that implement IEnumerable<T>
, and so if they have, e.g., IEnumerable<GpxRoute>
that's being created by a LINQ query, then it would be wasteful to force it to go through a .ToArray()
just to meet the demands of the API.
If you think it would help usability significantly, then I wouldn't mind doing something like this:
public static void Write(XmlWriter writer, GpxWriterSettings settings, GpxMainObject gpx)
{
Write(writer, settings, gpx.Metadata, gpx.Waypoints, gpx.Routes, gpx.Tracks, gpx.Extensions);
}
I never said anything about removing existing calls :-) The above suggesting is great IMO.
I'm missing a class to hold all the information that I can pass in memory from place to place. Currently the writer is getting a metadata object and three list of features (among other stuff). It would be nice to have a interface call to the writer that receives an object that hold all the information. Some thing like:
And the writer: