During #8, I posited that it might be better to tweak IFeature and/or IAttributesTable to better model the two different use cases that IAttributesTable supports:
- Some
IAttributesTable instances have their set of valid attributes defined by something external to the individual instance (e.g., shapefiles, GPX, relational databases).
- With these kinds of tables, you can tell when certain attributes are missing, and what type of data is they would need to hold when set.
- Other
IAttributesTable instances are more dynamic and can hold any data, or at least the system isn't supposed to reject anything outright (e.g., GeoJSON).
- With these kinds of tables, you can add just about anything without errors.
From a reader's perspective, there's no difference between the two, but a writer who consume just the interface(s) would appreciate knowing what the rules are at compile-time.
Perhaps the interface(s) only need to support reading, and writing could be handled by using the concrete type directly. Alternatively, perhaps we can take a similar approach to what .NET did with its read-only collection interfaces, and expose a "read-only" base interface with different sub-interfaces that support the different kinds of writing.
Original question that sparked this issue:
Can IAttributesTable / AttributesTable be replaced with just IDictionary<string, object> directly on the Feature class?
That's basically all this is, anyway...
During #8, I posited that it might be better to tweak
IFeatureand/orIAttributesTableto better model the two different use cases thatIAttributesTablesupports:IAttributesTableinstances have their set of valid attributes defined by something external to the individual instance (e.g., shapefiles, GPX, relational databases).IAttributesTableinstances are more dynamic and can hold any data, or at least the system isn't supposed to reject anything outright (e.g., GeoJSON).From a reader's perspective, there's no difference between the two, but a writer who consume just the interface(s) would appreciate knowing what the rules are at compile-time.
Perhaps the interface(s) only need to support reading, and writing could be handled by using the concrete type directly. Alternatively, perhaps we can take a similar approach to what .NET did with its read-only collection interfaces, and expose a "read-only" base interface with different sub-interfaces that support the different kinds of writing.
Original question that sparked this issue: