Your skill will accomplish
what the force of many cannot
Is what you want available?by Lady_Aleena (Curate)
|on Jun 08, 2017 at 22:07 UTC||Need Help??|
As some of you may know, I am trying to become a better Perl writer. Part of it is finding where I wrote something that can be done better by someone else and using the better way.
One time I needed to do a numeric comparison of months written as text. So I wrote a module to get the month numbers needed. After I wrote it, I found to my dismay, I had not needed to write it. Date::Calc had a subroutine called Decode_Month that was much better than what I wrote. I am so embarrassed I did not think to look in Date::Calc first before I wrote my silly little module. Date::Calc is far better at date manipulation than anything I could write. So, I dropped the use of my module for Date::Calc. It was a learning experience I took forward to the rest of my code.
Another part of becoming better is rewriting and renaming the modules I have written. To find names for my modules, I have been crawling CPAN to find what name spaces already exist.
I was looking for a new name for my Util::Number module. I crawled CPAN and found "Number" is a top name space. Then I found Number::Format. I sighed thinking my little Util::Number's days were numbered. Number::Format has a subroutine called round and so did Util::Number. Both do the same thing. Number::Format has a subroutine called format_number that puts commas in numbers and rounds numbers together, just like commify and my pretty_number. I thought commify and pretty_number were not going to be able to match format_number's power.
So, I installed Number::Format and was going to discontinue using my Util::Number. Why? Using Number::Format in code that I need help with, you can install it from CPAN without any trouble. Using Util::Number in code that I need help with, you would have to guess at what it does unless I also put Util::Number in the node with my problem code.
So, I was changing over my code from pretty_number to format_number and making sure it returned what I wanted. Then I got a big surprise. format_number has limitations commify and pretty_number do not have. format_number can not put commas into very big numbers. It outputs an error about the big number and suggests using Math::BigFloat.
In the change over from commify and pretty_number to format_number, I got another surprise. format_number does not do ordinal numbers either. I fed it an ordianal number in Happy unbirthday redux! and other birthday stuff, and it returned the following error.
So, I went back to commify in my code and got...
This was all so surprising to me. Here I was ready to use a module readily available on CPAN instead of my own silly little module, but the CPAN module could not do what mine does. I was thinking "But it's is so much better than mine. It's got all those bells and whistles. And it's on CPAN!"
This is not a rant against Number::Format. It is on CPAN and is better written than my little Util::Number. I will use Number::Format in code when I need help. Number::Format also has options I do not currently have, so I will be using it whenever one of those options is needed. Util::Number may become a fallback module when Number::Format will not work for what I am doing currently. Util::Number will not be going to CPAN since I did not write commify or round, I just put them together in pretty_number.
I am trying to make my modules more useful with better names and code. I am also trying to get better by using what is already available. However, sometimes, what is available is a little less than what is wanted. That does not mean I will stop searching.
I cracked opened my now disused month module just to look at it. Then I saw the hash of arrays. What do I do with hashes of arrays of similar data? I randomize it of course. So my Util::MonthNumber is now Random::Month... 8)
No matter how hysterical I get, my problems are not time sensitive. So, relax, have a cookie, and a very nice day!