I draw a big distinction between that and algorithmic inefficiency which can cause code to fall over surprisingly fast.
Not that I doubt you, but could you please be more specific as to why you think this code will "fall over surprisingly fast". I mean, maybe you are correct, but I would think one would need to really analyze the code, and runs some tests/benchmarks before making such a strong declaration.
As for the API, pass me the information any way you want. All of the options that you mention are supported if I get the following information:
I will only just say that this contradicts the efficiency argument, since it requires you to do two (possibly unnessecary) hash lookups for each loop of the sort.
To be honest, I am not really looking to argue with you about this, but only to point out that your comment , which was very short, made some assumptions which while not wholly wrong, were not really all that right either and certainly were not founded upon use or study of the module in question. You being a high level saint, and a long standing member of this community means that many people listen to and place value on what you say. To make quick, ambigious and somewhat disparaging comments about a module you have never used and never plan to use is (IMO) not really useful to the discussion.
In reply to Re^6: RFC - Tie::Hash::Ranked
by stvn
in thread RFC - Tie::Hash::Ranked
by Limbic~Region
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |