Big Number::Phone update soon

There's lots of changes coming soon to Number::Phone - see github for a sneak preview.

They're mostly as a result of me pulling in data from Google's libphonenumber and automatically generating perl classes for all of the countries which I don't already handle. I refer to these as "stub" classes, because while many of them do have a lot of data, some don't, and in any case libphonenumber is missing some features that "full-fat" Number::Phone subclasses support. This isn't a criticism of libphonenumber, it's just a result of the two projects aiming at slightly different targets: libphonenumber is primarily designed for embedding in handsets; Number::Phone was primarily designed for telco billing, routing, and provisioning.

So, the major changes in detail ...


  • when no really detailed country-specific subclass is available, then instead of returning a Number::Phone::StubCountry that only knows what country it represents, Number::Phone->new() will return a Number::Phone::StubCountry::XX object that supports many of the methods such as areaname() and is_mobile();

  • this also fixes a rather embarrassing bug in the old Number::Phone::StubCountry where the country_code() method worked, returning the E.164 international dialing code, but country() didn't return the ISO 3166 country code;

  • I used to support all kinds of crazy ways of calling my methods - as object methods, as class methods, even as subroutines. This was a stupid design decision that I made "to make things easier for the user" but in reality it was just a source of bugs. These will start throwing deprecation warnings which you can't turn off, and will be removed in a later release;

1 Comment

Thanks for pointing out about libphonenumber, interesting project (as Phone::Number also is). Today I feel glad that I only maintain a specific country's phone number library :)

Leave a comment

About David Cantrell

user-pic I'm in yur test resultz analyzn yr failz