Skip to content

Remove NodaCultureInfo, and make NodaFormatInfo internal #131

@GoogleCodeExporter

Description

@GoogleCodeExporter
NodaCultureInfo and NodaFormatInfo have a confusing design:
- they should probably either be a single object or have a one-way 
relationship, not the bidirectional relationship they currently have.
- they are optionally-mutable (like CultureInfo, to be fair)
- NodaCultureInfo creates and caches a NodaFormatInfo on demand, but doesn't 
play nicely with mutability (see issue 130).

Offhand, it's not entirely clear what we'd lose if we made both classes 
internal for 1.0, other than the ability to define a custom default format for 
Noda Time-specific objects, or specify a custom format for compound formatters. 
 (Note that you can always format explicitly via a pattern.)

I'd like to explore what impact making the two classes internal would have for 
1.0.  We can always reverse that decision for 1.1, if we decide it was a bad 
idea, but doing so would allow us to spend a bit more time making sense of this 
without committing to it before a 2.0 release (see issue 96).

Original issue reported on code.google.com by malcolm.rowe on 26 Oct 2012 at 8:35

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions