NeoFormatter --> Formatter

[sffc]

#1317

Also hides the neo module, making future moving of types easier

[sffc]

I thought we had consensus on this but @robertbastian made some good points that Formatter by itself is not consistent with the style guide, for good reason.

What should I name it?

I can introduce type aliases such as pub type DateFormatter = Formatter<YMD> but this won't cover all cases.

[robertbastian]

pub type DateFormatter = GenericFormatter<YMD>

[robertbastian]

ah that doesn't work because it's doubly generic, and we'll end up with TypedGenericFormatter.

It generic in a FieldSet, so FieldSetFormatter?

[Manishearth]

FieldSetFormatter feels too inside baseball

[robertbastian]

.

[sffc]

I'd like this discussion resolved ASAP because I want it for the Alpha release and the UTW presentation.

Does anyone have other bikesheds they want to toss in the hat?

[Manishearth]

I'm ultimately fine with Formatter. I think if Temporal were not taken by ECMA I would find TemporalFormatter interesting.

I don't think there's a good generic term for "formats a lot of things that do with time but not things that are unrelated to time" without calling it TimeFormatter, and that's wrong.

[robertbastian]

FieldSetFormatter feels too inside baseball

is FieldSet not something we expose, and explain in docs?

[Manishearth]

@robertbastian We do, but I don't want every user to have to think about it, plus it's not super discoverable. I'm fine with it as a component of our system, but not for discoverability. I find icu_datetime::Formatter to be more discoverable than icu_datetime::FieldSetFormatter.

I think people can learn about fieldsets after they discover and try to use this type, it feels weird for them to be expected to make that connection so that they discover this type and decide it is what they want. I'd probably gloss over a type named FieldSetFormatter because I'd go "I'm not formatting field sets, I don't even know what those are!", and go look for a formatter elsewhere.

[robertbastian]

I think the main entry point should be type aliases. Users can learn about FieldSetFormatter after they learn about field sets.

[sffc]

If we wanted the entrypoint to be the type aliases, we would need a large number of type aliases, basically one per field set. YearMonthFormatter, YearMonthDayFormatter, HourFormatter, HourMinuteFormatter, etc. We could consider adding DateFormatter but users should prefer using the field-set-specific formatter.

Also, this gets us into naming problems again. I think it should be Hour_Minute_Formatter. We avoid this by making it icu::datetime::Formatter<HM>.

[Manishearth]

If we wanted the entrypoint to be the type aliases, we would need a large number of type aliases

string agree! I'm not strongly opposed to doing all the aliases, but I do think it would be a pain, and I don't really want to commit to that right now.

I think we have a good reason to deviate from style here with Formatter, it formats a large set of things without formatting all things.

This said, it would be pretty cool if we could produce a souped-up utility type GenericFormatter that does fixeddecimal/currency/datetimezone/etc and uses a built up version of the GetField infra here.

[sffc]

Replaced by #5708