Fix feet inches

[tmilnthorp]

I think we need to fix#794 by constructing the Regex with the separators.

This now passes except for two tests:

• ParseWithCultureUsingDotAsThousandSeparators_ThrowsExceptionOnInvalidString actually now passes (more forgiving regex parses successfully)
• ParseLengthToMetersUsEnglish with 1e-3 km fails (regex doesn't handle engineering notation).

I feel it's closer, but we should handle engineering notation.

[tmilnthorp]

newobject[]{"1’000′",1000,newCultureInfo("de-CH")},// Feet only, with seperatornewobject[]{"1’000′ 6\"",1000.5,newCultureInfo("de-CH")},// Normal form, using separators for culture

Are the new tests with culture specific separators. The rest are all en-US format so being explicit.

[angularsen]

@pgrawher also pointed out that in some Windows/Linux/Mac versions, the apostrophe symbol can vary for the same culture. But, unless we actually run into this issue on our own machines and the AppVeyor VMs, then I think a hard coded string is better. I really don't expect this character to change much over time for a given culture unless they are fixing a consistency bug in one of the OS versions, but I am merely speculating.

[angularsen]

For the sake of reviewing this PR, it would be better if you did the refactoring to memberdata in a separate PR, but it helps to know that these were the only two new cases plus the new culture parameter.

[angularsen]

Aren't you missing the problematic test case? Where the thousand separator character exactly matches the foot or inches unit? Requires a culture that has this exact character though, can construct our own if necessary.

new object[]{"1′000′", 1000, new CultureInfo("de-CH")},

[pgrawehr]

Use new CultureInfo("...", false) everywhere. This makes sure that at least when developers use a similarly current version of Windows, the settings will be the same. (This ignores any manual overrides in control panel)

[angularsen]

@pgrawher also pointed out that in some Windows/Linux/Mac versions, the apostrophe symbol can vary for the same culture. But, unless we actually run into this issue on our own machines and the AppVeyor VMs, then I think a hard coded string is better. I really don't expect this character to change much over time for a given culture unless they are fixing a consistency bug in one of the OS versions, but I am merely speculating.

[angularsen]

For the sake of reviewing this PR, it would be better if you did the refactoring to memberdata in a separate PR, but it helps to know that these were the only two new cases plus the new culture parameter.

[angularsen]

Won't this allow invalid formats like inches first, feet after? 5" 1'
Or is this actually an acceptable form?

[tmilnthorp]

You're right, it wouldn't. I'll make sure to enforce ordering.

[angularsen]

Aren't you missing the problematic test case? Where the thousand separator character exactly matches the foot or inches unit? Requires a culture that has this exact character though, can construct our own if necessary.

new object[]{"1′000′", 1000, new CultureInfo("de-CH")},

[tmilnthorp]

Indeed I did miss the problematic case!

I wonder if it would help simplify everything if we just search for the abbreviation ending, and just do a double.Parse or double.TryParse on the prefix.

In other words, parse the abbreviation suffix ourselves and let .NET parse everything before it. They've already done all the work - no sense in recreating the parsing regex.

[angularsen]

In other words, parse the abbreviation suffix ourselves and let .NET parse everything before it.

Isn't that how the regex is designed though? To only split the string on known abbreviations and use double.TryParse on whatever was in front of the abbreviation?

I may remember it wrong.

[tmilnthorp]

In other words, parse the abbreviation suffix ourselves and let .NET parse everything before it.

Isn't that how the regex is designed though? To only split the string on known abbreviations and use double.TryParse on whatever was in front of the abbreviation?

I may remember it wrong.

It is, kind of. It fails when there's an extra apostrophe as this defect shows :)

My regex knowledge fails me here. We want to take everything until the last abbreviation string at the end. Almost as if to reverse the string or do a maximum look-ahead of some sort.

[angularsen]

Are we simply overcomplicating this?
Do we really need to support 1'500' 2" ? Is this a realistic usecase?
Can we throw if there is more than two matches of each foot/inch abbreviation?

I'm sure we can get it working, but it just feels very complicated for something perhaps no one will ever benefit from. Maybe we can implement it properly if someone complains about this exception for scenarios like that?
At least we don't give out incorrect values, which is a whole lot worse.

In my feeble metric mind, I speculate these are the typical use cases:

• Integers: 5' 2"
• Fractions: 5 1/4"
• Decimal point for either foot or inch, not both: 1.5' or 1.5", but I think fractions are more common?
• Thousand separators for either foot or inch, not both: 1'500' or 1'500" (one thousand five hundred feet)

[pgrawehr]

I agree that we do not need the perfect solution here. I think it's ok to throw if something is ambiguous. But we should a) throw in a defined way and b) have all the unit tests pass regardless of the dev's culture settings. The fact that b) is currently not true was the reason I started all this.

[tmilnthorp]

I disagree, we should handle any culture (or grouping separator) gracefully.

We can't even round-trip right now for some cultures. The following throws a FormatException:

varfeetInches=newFeetInches(1234,5);varculture=newCultureInfo("de-CH");vardeCHString=feetInches.ToString(culture);varparsed=Length.Parse(deCHString,culture);

deCHString is: 1’234 ft 5 in

[angularsen]

I guess you make a fair point about the round-trip of ToString/Parse.