Skip to content

Redesign IFeature / IAttributesTable to better model the different use cases it solves #6

@airbreather

Description

@airbreather

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:

  1. 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.
  2. 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...

Metadata

Metadata

Assignees

No one assigned

    Labels

    breaking changeDoing this would break either source or binary compatibility with existing versions.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions