Closed theory closed 10 years ago
Thanks, merged. This looks very useful.
However, I think it could do with a bit more work, mostly in how the stub classes for NANP are built. They're huge, and repeat lots of data - for example, N:P:StubCountry:JM knows about numbers in Dallas, even if it would never get instantiated with a Dallas number. This makes the tar.gz file balloon from its already huge 7MB to 11.
Most of the bloat is in the generated areaname() sub, so that should only know about those areas within the relevant country - or it could use the data that's already in Number::Phone::NANP::Data.
That said, if I have to do another release for any reason before either of us get round to fixing this, then I'll release anyway - disk space and bandwidth is cheap these days :-)
Is the NANP stuff generated from the libphonenumber data? Because I didn't think I touched NANP stuff at all.
Yes. Well, the areaname() method is anyway. They don't actually know about things like whether a number is a cell phone - I should probably add that.
But never mind, I've drunk too much coffee this evening so am fixing this right now instead of doing anything sensible like going to bed.
... and done. But it would probably be a bad idea to do a release at 1am so that can wait until later!
I see. Do we know that they're all identical between the ::NANP modules and the stubs? Does the data agree?
They agree as far as my manual testing has gone - which is expected, they both derive area names from libphonenumber's /trunk/resources/geocoding/en/1.txt - but I need to add proper test cases to make sure that they stay agreed and I don't break it later.
Add Number::Phone::Lib, which returns only libphonenumber-based implementations. This makes it more compatible with other implementations in Java, Ruby, JavaScript, etc., at the expense of failing to validate UK numbers that Number::Phone::UK understands. Given the overhead of the Number::Phone::UK database, this seems like a decent-enough tradeoff for those who need the performance.