Feature Request #4350

money and currency helper functions in Num

Added by Jim K almost 3 years ago. Updated almost 3 years ago.

Status:ClosedStart date:11/30/2011
Priority:NormalDue date:
Assignee:Woody Gilk% Done:

0%

Category:-
Target version:-
Resolution:wontfix Points:1

History

#1 Updated by Steven G. almost 3 years ago

Jim K wrote:

https://github.com/jimktrains/kohana-core/blob/11205d64cad1aed3137224058a65735c40b23ee6/classes/kohana/num.php#L89 would the currency and money functions be useful in Num?

I say nay. This is something that is very specific to where you are in the world and what you're dealing with, so it's better to leave it out, so the developers are forced to think about it; and they are going to have to think about it anyway.

The implementation also seems wrong. The Num::format method is plenty of help from kohana's part. Just how the currency symbol is displayed (where it's placed, before, after or in the middle; and which one is used, $ or USD) should be completely up to the developers.

#2 Updated by Steven G. almost 3 years ago

Why is this in Cache?

#3 Updated by Jim K almost 3 years ago

I'm not sure why it's in Cache. I didn't even know there were sections:(

I say nay. This is something that is very specific to where you are in the world and what you're dealing with, so it's better to leave it out, so the developers are forced to think about it; and they are going to have to think about it anyway.

The implementation also seems wrong. The Num::format method is plenty of help from kohana's part. Just how the currency symbol is displayed (where it's placed, before, after or in the middle; and which one is used, $ or USD) should be completely up to the developers.

Why should ever programmer have to re-invent the wheel? My exact functions would not be exactly what I submit (they're a tad US-centric, but it's not difficult to have a small set of rules or configuration for these things. If the developer needs something other than what we provide (which should be as close to possible for "right" for the locals we support) they can always implement their own functions.

I imagine supplementing localeconv with config settings that state if, for each locale, the:

  • text currency is show
  • symbol currency is shown
  • text currency is before or after the value
  • symbol currency is show before or after the value
  • symbol currency is to the right or the left of the text currency

That, plus localeconv, should be more than enough information to create a flexible system for the majority of currencies.

#4 Updated by Steven G. almost 3 years ago

Jim K wrote:

Why should ever programmer have to re-invent the wheel?

The wheel is already there, under the form of Num::format. Why should kohana make the wheel complicated? :)

Currency, beyond just formatting a number, is outside the scope of the Num class, IMO. These methods along with other functionality should be in a Currency class, perhaps even in it's own module, bundled with things like a cart implementation and so on.

Regarding your configuration idea. I don't think that's correct either. The function should be able to decide by itself how it needs to be displayed. So if you have a site that displays several types of currency, both of which display differently, you are not forcing one to display wrong to make another display right. You also need to make a system by which the developer can supply a currency into the function. All in all it all seems like a very magical which tends to mean using it is going to end up in much more complicated code then if you just let the developer handle it himself.

#5 Updated by Jim K almost 3 years ago

The wheel is already there, under the form of Num::format. Why should kohana make the wheel complicated? :)

Obviously it's not, or I wouldn't have had to write my code. It's not more complicated, honestly. It adds functionality while not removing what is there.

Currency, beyond just formatting a number, is outside the scope of the Num class, IMO. These methods along with other functionality should be in a Currency class, perhaps even in it's own module, bundled with things like a cart implementation and so on.

If we have a function to format a number as a currency based on the local, why not take the extra step and add the currency in? While I could see breaking some things out into a Money or Currency class, saying it belongs in a card implementation is much too much.

Regarding your configuration idea. I don't think that's correct either. The function should be able to decide by itself how it needs to be displayed. So if you have a site that displays several types of currency, both of which display differently, you are not forcing one to display wrong to make another display right. You also need to make a system by which the developer can supply a currency into the function. All in all it all seems like a very magical which tends to mean using it is going to end up in much more complicated code then if you just let the developer handle it himself.

The configuration I mentioned would be based on Locale, and possibly currency, not an absolute across the site. (That's what I meant by supplementing localconv.)

So, for instance, in the same code base Num::currency(4.3) would return "$4.30"f the locale was in the US and "SYM 4,300" for some other currency, based on the locale.

However, if I go Num::currency(4.3, 'en_US') I would get "$4.30" regardless of locale.

Additionally, I would also advocate a 3rd optional param for an "instance" config that would be merged into the config for the locale: Num::currency(4.3, 'en_US', array('show_text_currency_symbol'=>true)) would return "USD $4.30".

#6 Updated by Jim K almost 3 years ago

I should note, that I'm in the process of adding these functions in for a project I'm working on anyway. I would be submitting it back, at least as a module. I was hoping to get some input from the community on how they felt the best way to arrange it would be. This is less of a feature request than a "This is being written anyway. If it has any chance of being merged into the core, what would you like to see in it" request.

#7 Updated by Steven G. almost 3 years ago

Jim K wrote:

While I could see breaking some things out into a Money or Currency class, saying it belongs in a card implementation is much too much.

I was talking about the module not the class. As in, you would have a Cart implementation and classes for working with money, displaying money, etc, in one module. Sorry if my wording was confusing, can't really edit comments here.

If we have a function to format a number as a currency based on the local, why not take the extra step and add the currency in?

The function in question formats a number, that's it. The reason for the monetary parameter being there is because monetary numbers are formatted slightly differently, so obviously the function would produce bad output if it wasn't there. That doesn't make it a money function. :)

#8 Updated by Jim K almost 3 years ago

I don't think a cart implementation is the place for this.

The function in question formats a number, that's it. The reason for the monetary parameter being there is because monetary numbers are formatted slightly differently, so obviously the function would produce bad output if it wasn't there. That doesn't make it a money function. :)

It only produces bad output because we now expect it to properly format money. If all it does was format a number, it would be doing it correctly. I would argue that if you're using the function to format a number as a monetary unit, it would be extraordinary useful to also actually format the currency as well.

#9 Updated by Woody Gilk almost 3 years ago

  • Status changed from New to Closed
  • Assignee set to Woody Gilk
  • Resolution set to wontfix

Currency display is very region/language/locale dependent, I don't think this is a good solution for a difficult problem.

#10 Updated by Woody Gilk almost 3 years ago

  • Project changed from Cache to Kohana v3.x

Also available in: Atom PDF