6 ms·

The issue really exists only at I/O boundaries, where if there is a format mismatch you have to convert, which incurs some costs (CPU mostly, and memory bandwid

The issue really exists only at I/O boundaries, where if there is a format mismatch you have to convert, which incurs some costs (CPU mostly, and memory bandwidth). Most languages can inline the data such that there isn't much overhead in accessing the raw bytes. Arrays with aliases for indexes (like you did, or in JS maybe I'd do something like `const LAT = 0, LON = 1; point[LAT]`, C-family languages can pack the bytes into tight structs where field names act as aliases to the memory location, Haskell has the UNPACK pragma etc. Btw, give that you have a PointCoordinates type, why not f(p: PointCoordinates)?

jillesvangurp 5y ago
The issue is code readability while dealing with memory efficient arrays of DoubleArrays, which are used by geojson to represent geometries. You are right about the function call :-). Actually you can also do fun PointCoordinates.f() {...}. The reason I have function calls with latitude and longitude in there as equivalents for their point coordinate variants is just convenience. If you have some other library using its own point representation, having to first convert to my representation before you can use my functions is a bit verbose. And of course, people into OO programming usually get a bit carried away reinventing their own Point classes. It's one of the reasons I stayed away from using object hierarchies in this library. The geojson classes are an exception to this and were actually bolted on fairly recently so I can support geojson compatible serialization/deserialization.