-
Notifications
You must be signed in to change notification settings - Fork 14
Description
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
IAttributesTableinstances 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
IAttributesTableinstances 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/AttributesTablebe replaced with justIDictionary<string, object>directly on theFeatureclass?That's basically all this is, anyway...