Deprecating GlobalPhone in favor of libphonenumber-csharp? about libphonenumber-csharp HOT 6 CLOSED

The wrapper is certainly an option, would want to use floating versioning to not need to update every time there's new metadata. This port tries to do it's best to stay true to the Java source and its API while also adhering to C# styles and paradigms. The builder for PhoneNumber is the only major place that those two are particularly at odds. I use use phoneNumberUtil.Parse([E164 Number], null) in place of what ideally would be a constructor. The PhoneNumber class is autogenerated from the Google proto and I would rather not diverge from that.

from libphonenumber-csharp.

I see no reason why not, assuming that the migration path isn't too onerous. But given the age of the last release there's been quite a deal of updates it would be missing, 833 is the first thing that comes to my mind.

from libphonenumber-csharp.

Having a migration path would be nice. Another alternative is to use reimplement GlobalPhone as a set of extension methods and or wrappers to make it more c#-y.

from libphonenumber-csharp.

What do you think is the best way forward?

from libphonenumber-csharp.

Or is it only the builder that looks a bit non c#-y?

from libphonenumber-csharp.

Yes, that makes sense. I've not had the time to look into making any changes related to this.

from libphonenumber-csharp.