number_to_human_size helper

[Mike Orr]

There's a ticket to reinstate number_to_human_size(), one of the
deprecated Rails helpers. I left it as (1) the current implementation
is not robust enough, (2) there are two alternative implementations
which are better in different ways but arguably not ideal either.
This thread discusses the issues:

http://groups.google.com/group/pylons-discuss/browse_thread/thread/77ea051e9dbbd6e3?pli=1

Nobody has followed up with suggestions for a better API spec. Should
I ask again for volunteers, leave the ticket open, or just close it?
My concern is this is too implementation-specific an issue to come up
with an API that would work for a wide variety of users, which is our
threshold for helper acceptance.

--
Mike Orr <slugg...@gmail.com>

[Jorge Vargas]

On Mon, Dec 1, 2008 at 5:31 PM, Mike Orr <slugg...@gmail.com> wrote:
>
> There's a ticket to reinstate number_to_human_size(), one of the
> deprecated Rails helpers. I left it as (1) the current implementation
> is not robust enough, (2) there are two alternative implementations
> which are better in different ways but arguably not ideal either.
> This thread discusses the issues:
>
> http://groups.google.com/group/pylons-discuss/browse_thread/thread/77ea051e9dbbd6e3?pli=1
>
> Nobody has followed up with suggestions for a better API spec. Should
> I ask again for volunteers, leave the ticket open, or just close it?

I believe your suggestion on that thread is good enough, with the
little parameters change I made here
http://groups.google.com/group/pylons-discuss/msg/e221dc7a7bbc4d71

do you have code for that or is that what your asking for here?

> My concern is this is too implementation-specific an issue to come up
> with an API that would work for a wide variety of users, which is our
> threshold for helper acceptance.
>

there is always the case where you could copy it into your project and
modify it as needed, sometimes that is better than starting from zero.

as for number_to_phone, that could be changed into usphone because I
really don't think there is a universal phone parser, in fact it
should probably be a bad idea. From my experience doing non-us you
have
calling_code + country_code + area_code + number + extension

calling_code is country dependent, sometime it even depends on the
country your calling to and from. For example from Dominican Republic
you will say 001 to call to non-USA but 1 to call USA.
contry_code, is fairly normalized into a 3 digit code, for example
Costa Rica is 305, Dominican Republic is 809 and 829 (last one since
last year)
area_code, sometimes there is a lack of country_code and this is used
instead, and country code is another number
number, and here is where things break some countries have followed
the US standard so they have 3+3+4 digits = area_code + trunk + number
but others have follow the France? standard which just adds up numbers
so they have 8 or 9 digits as the number (ie no area code), and others
due to international calling codes have a mix.

So to summarize the fun if I'm calling from Dominican Republic to
Costa Rica I'll input
011-506-ZZZZ-QQQQ
XXX-YYY-ZZZZ-QQQQ
where X and Y is only need if the call starts at DR.
but if i'm calling from CR to CR
then that will just be
ZZZZ-QQQQ
but the other way around (CR-> DR)
1-809-ZZZ-QQQQ
1-829-ZZZ-QQQQ
X-YYY-ZZZ-QQQQ
but if I'm calling from DR to DR
then I need to drop the X, unless it's a cellphone.


bottom line this is a total mess, and I don't think it's worth trying
to push them all into one helper, maybe the strftime option is a good
idea, although I think having several functions will be far simpler.
So we could have number_to_XXX_phone, where XXX is the standardized 3
letter country code.

> --
> Mike Orr <slugg...@gmail.com>
>
> >
>

[Wojciech Malinowski]

Mike Orr wrote:
> Nobody has followed up with suggestions for a better API spec. Should
> I ask again for volunteers, leave the ticket open, or just close it?
> My concern is this is too implementation-specific an issue to come up
> with an API that would work for a wide variety of users, which is our
> threshold for helper acceptance.

In the attached file you can find my proposal for the function name,
spec and implementation.

What do you think about it? Feel free to modify if anyone has an idea of
how to improve it.

Regards,
Wojciech Malinowski

[Jorge Vargas]

that's seems really good, +1

> Regards,
> Wojciech Malinowski
>
>
> >
>