Open ttencate opened 2 years ago
I'm in favor of wrapping these constants with enums.
#[non_exhaustive]
isn't worse than fiddling with these numbers.
wkbUnknown
as long as we don't know it.I honestly don't know what would be the best solution here, but I want to understand why you want this change.
gdal-sys
and type those OGRwkb
prefixes?All of the above. Plus the ability to implement useful traits like Debug
and Display
on the type (which would have made #250 more idiomatic).
What if we wrapped them in structs defined gdal
? Something like:
#[derive(PartialEq, Eq)]
struct GeometryType(u32);
impl GeometryType {
pub const Unknown: GeometryType = GeometryType(0);
pub const Point: GeometryType = GeometryType(1);
pub const LineString: GeometryType = GeometryType(2);
}
gdal-sys
and it has a nicer nameDebug
and Display
In what way is that better than an enum
though? If it's purely to allow unknown values through, we can also do that with an enum
.
You're right, it's not much better than an enum with an Unknown(u32)
variant. I guess it would avoid some mapping code from the enum to integers and back.
Previously discussed on #250. The question was how extensible it should be, which I've briefly looked into.
gdal_sys
crate needs updating with every new release anyway due to the generated bindings, so adding new constants to the Rust enum manually should not be too much trouble. Or after the fact if nobody has a need for them yet.#[non_exhaustive]
so that client code is forced to reckon with new additions to the enum.Note that the issues are mostly hypothetical at the moment;
OGRwkbGeometryType
has the same values in all of the supported GDAL/OGR versions.