Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Currency Component Proposal

Proposed Component Name Zend_Currency
Developer Notes http://framework.zend.com/wiki/display/ZFDEV/Zend_Currency
Proposers Thomas Weidner
Gavin (Zend-liaison)
Revision 2.0 - 18 July 2006: Changes because of comments from Zend
1.1 - 20 June 2006: Changed class to be static
1.0 - 20 June 2006: Initial release extracted from Zend_Locale and Zend_Unit. (wiki revision: 19)

Table of Contents

1. Overview

Zend_Currency is a Class which handles all Currency related functions and is locale aware.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • Handling of currency related issues
  • Works with locales

4. Dependencies on Other Framework Components

5. Theory of Operation

Converting between locales/Unit conversion

Can output in different locales
Hint: Does not convert between Currencies (f.e. from Dollar to EUR!!

Basically we have to implement/know the following standards

ISO 4217 - Currency Codes

6. Milestones / Tasks

zone: Missing {zone-data:milestones}

7. Class Index

  • Zend_Currency_Exception
  • Zend_Currency

8. Use Cases

Get a currency string (standard locale)

Different inputs for a currency

Get a currency string with different currency

Get a formatted currency string with different currency

Get a the standard currency for a spezified locale

Get currency datas of a locale

Maths with currencies

9. Class Skeletons

]]></ac:plain-text-body></ac:macro>

]]></ac:plain-text-body></ac:macro>

Labels:
None
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jun 20, 2006

    <p>Feels like this should just be a subset of Zend_Unit (<a class="external-link" href="http://framework.zend.com/wiki/display/ZFPROP/Zend_Unit+Proposal">http://framework.zend.com/wiki/display/ZFPROP/Zend_Unit+Proposal</a>). What is unique about this class?</p>

    1. Jun 20, 2006

      <p>Zend_Unit is meant to convert between different measurement types.<br />
      It can convert between GRAM and POUND for example.</p>

      <p>Zend_Currency is meant to format currency strings locale aware.<br />
      There are no convertions possible between different locales, as these will change every day in RL.</p>

      <p>That's the background why also in other programing languages the Currency is in a own class.</p>

  2. Jun 21, 2006

    <p>Hello,</p>

    <p>I just a little confused with some of the parameters used above. It might just be different in other countries (I'm in the U.K.), I'm not sure. </p>

    <p>In the first example :</p>

    <p>– echo $curr->toCurrency('23,6',Zend_Locale_Format::EUR); // outputs f.e. 23.6 eur</p>

    <p>Why is a comma used to seperate the fractional part of the value instead of a period? Using a period would follow normal use for denoting money values. </p>

    <p>The second example above shows this problem further :</p>

    <p>– $money = Zend_Currency::toValue('20.153,536 eur');<br />
    echo Zend_Currency::toCurrency($money);<br />
    // outputs 20153.536 eur</p>

    <p>In the above example a period is used where commas are normally used. The number 20.153,536 to me would output 20.153536 . If you wanted the output given in the example I would want to enter 20,153.536. </p>

    <p>Again, I'm not sure what formats are used in other countries, but I think what I've suggested might be the international standard. I might be wrong though. Thought I'd ask!</p>

    1. Jun 21, 2006

      <p>I'm an austrian fellow,</p>

      <p>in german the seperation between number and fractional part is done with comma.<br />
      What I want to say is, that the imput is parsed with the locale which is set as standard.</p>

      <p>When you have Zend_Locale::EN_UK as standard set, then your number string will be parsed as 20.153536.<br />
      When Zend_Locale::DE_DE is set as standard your number string will be parsed as 20153.536.</p>

      <p>It all depends on your set locale.<br />
      Of course you can give another locale when calling the function.</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      $money = Zend_Currency::toValue('20.153,536 eur',,Zend_Locale::DE_DE);
      echo Zend_Currency::toCurrency($money,,,Zend_Locale::EN_UK);
      // toCurrency will know that standard currency for en_UK is eur and will display
      // 20,153.536 for en_UK
      ]]></ac:plain-text-body></ac:macro>

      <p>Again... it's all related to locales.</p>

    2. Jun 21, 2006

      <p>Also note that in many Asian countries comma separation is every four zeroes. For example, in Japanese "hyakuman" (1 million, literally one hundred ten-thousands) might be written 100,0000.</p>

      1. Jun 21, 2006

        <p>This is nothing Zend_Currency has to be aware of.</p>

        <p>The formatting-rules as seperation, length, currency are handled from Zend_Locale_Format by LDML.</p>

        <p>Zend_Currency only asks how to format in the given locale.<br />
        So think of marsian currency or date, formatted "10 00 000 0000@00 000 0001".</p>

        <p>Zend_Currency doesn't know how to format things, it only has to ask Zend_Locale_Format <ac:emoticon ac:name="smile" /></p>

        1. Jun 22, 2006

          <p>Sorry, after re-reading my comment I see I wasn't very clear at all.</p>

          <p>My point was that not everyone who uses ZF will come from the US (as is evident by these comments), and so Zend_Currency may need to accept values in various formats as well as consult with Zend_Locale on how to format the return value. In other words, you might need to identify what locale you're converting <strong>from</strong>, in addition to what locale you're converting <strong>to</strong>.</p>

          1. Jun 22, 2006

            <p>That was already answered by me in the Comment for Chris.</p>

            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            When you have Zend_Locale::EN_UK as standard set, then your number string will be parsed as 20.153536.
            When Zend_Locale::DE_DE is set as standard your number string will be parsed as 20153.536.

            It all depends on your set locale.
            Of course you can give another locale when calling the function.
            ]]></ac:plain-text-body></ac:macro>

            <p>This means when you have set your standard locale to EN_UK your currency will be parsed with this locale</p>

            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            $onlyvalue = Zend_Currency::toValue($mycurrency);
            ]]></ac:plain-text-body></ac:macro>

            <p>So you make a real value or string from a currency input using your locale or an given one like this:</p>

            <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
            $onlyvalue = Zend_Currency::toValue($mycurrency, 'rounditwith2afterseperation', $otherlocalethanmystandardone);
            ]]></ac:plain-text-body></ac:macro>

            <p>Same goes for Zend_Currency::toCurrency. </p>

            <p>But that was already answered in a previous comment.</p>

  3. Jun 21, 2006

    <p>Thanks Thomas, that has cleared it up for me. </p>

    <p>P.S. Standard currency for UK is £(pound) not eur(yet!) <ac:emoticon ac:name="smile" /></p>

  4. Jun 24, 2006

    <p>Honestly, the more I look at this, the more I question why it's needed at all. First and most importantly, there's the native PHP function <strong>money_format()</strong> which handles everything this class is doing, that I can tell. Also, it seems that one of the examples indicated someone might use this to convert to whatever currency a country is using (without knowing the currency type first), which would frankly be a little scary.</p>

    <p>Also, the class might confuse some people, who might expect it to actually convert the currency (e.g., 1 USD = 0.548 GBP).</p>

    <p>Given <a class="external-link" href="http://www.php.net/manual/en/function.money-format.php">http://www.php.net/manual/en/function.money-format.php</a>, can you explain how this proposal would be different?</p>

    1. Jun 24, 2006

      <ul>
      <li>money-format does not support ISO 4217</li>
      <li>Zend_Currency uses LDML so it is extensionable</li>
      <li>money-format does not work on windows-systems</li>
      </ul>

      <p>I'm programming multi-language webapps on windows since 4 years, and more than 1 time I had use of this functionality.</p>

      1. Jun 24, 2006

        <p>I see, thanks. But I think the "currency" part may be a bit deceptive. Doesn't this apply to all numbers, not just monetary amounts? It seems like the words "number", "format", and "locale" need to be in the name. Like... Zend_Locale_NumberFormatter? That's pretty long, but it seems more descriptive than Zend_Currency.</p>

        1. Jun 25, 2006

          <p>Zend_Currency is an extension of Zend_Locale_Format.</p>

          <p>Zend_Currency doesn't only handle Number Formatting.<br />
          Currency has to know: </p>
          <ul>
          <li>Which currency sign to use</li>
          <li>Where to place it (befor or after)</li>
          <li>How to round it (not all are rounded by 2)</li>
          <li>How to place the seperation signs (not all currencies do seperate by thousand)</li>
          </ul>

          <p>Zend_Currency is only meant to handle Currency related functions.<br />
          Plain Number Formatting is intent to be done in Zend_Locale_Format.</p>

  5. Jul 17, 2006

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Feedback</ac:parameter><ac:rich-text-body>
    <p>Zend_Currency is conditionally accepted subject to the clarification and<br />
    change listed below.</p>

    <p>A ZF default locale object should be used in most places where a<br />
    component or function expects an optional locale object.<br />
    The default locale object should be constructed from an instance of<br />
    Zend_Config shared by all ZF components.</p>

    <p>To clarify the motivation for distinguishing between currency<br />
    normalization/formatting/parsing and number<br />
    normalization/formatting/parsing, would you provide a couple clear<br />
    examples where these processes are different for the same locale object</p>

    <p>There are many examples, but would you point out a good example<br />
    demonstrating the motivation?
    <a class="external-link" href="http://unicode.org/cldr/apps/survey?_=bn&x=currencies&skip=160">http://unicode.org/cldr/apps/survey?_=bn&amp;x=currencies&amp;skip=160</a></p>

    <p>Include getCurrencySymbol(). This can be useful for table column headings.</p>

    <p>Instances should be serializable.</p>

    <p>Parsing, normalization, conversion, and formatting function names<br />
    could benefit from sharing common looking names with other locale-related<br />
    classes.</p>

    <p>Methods should not combine input parsing, normalization, and output<br />
    formatting all in one step. Instead, parsing and normalization could be<br />
    encapsulated by a constructor. Then a "formatTo($someLocale)" can be<br />
    applied to the instance. This implies that Zend_Currency should yield<br />
    instance objects, and that an internal "normalized" form exists.</p>

    <p>Most currency formats render similarly to numbers in the same locale,<br />
    often differing only in the number of decimal digits. Obviously,<br />
    redundancy of code in the implementation of locale classes should be avoided.</p></ac:rich-text-body></ac:macro>

    1. Jul 18, 2006

      <blockquote>
      <p>A ZF default locale object should be used in most places where a<br />
      component or function expects an optional locale object.<br />
      The default locale object should be constructed from an instance of<br />
      Zend_Config shared by all ZF components.</p></blockquote>
      <p>All locale parameters for functions are optionally.<br />
      When the parameter is not given, the standard locale<br />
      will be taken from the browser or standard config</p>
      <blockquote>
      <p>To clarify the motivation for distinguishing between currency<br />
      normalization/formatting/parsing and number<br />
      normalization/formatting/parsing, would you provide a couple clear<br />
      examples where these processes are different for the same locale object</p></blockquote>
      <p>Normalization, Formatting and Parsing will be done by<br />
      Zend_Locale_Format. This means that for example<br />
      Zend_Measure and Zend_Currency will call the same function<br />
      Zend_Locale_Format::getValue. So all Normalization, Formatting and<br />
      Parsing is intend to be done by Zend_Locale_Format.</p>
      <blockquote>
      <p>There are many examples, but would you point out a good example<br />
      demonstrating the motivation?<br />
      <a href="http://unicode.org/cldr/apps/survey?_=bn&x=currencies&skip=160">http://unicode.org/cldr/apps/survey?_=bn&amp;x=currencies&amp;skip=160</a></p></blockquote>
      <p>Which motivation do you mean ?<br />
      Maybe the new examples will make the "motivation" for doing this class clearer</p>
      <blockquote>
      <p>Include getCurrencySymbol(). This can be useful for table column headings.</p></blockquote>
      <p>I added some new functions to cover this.</p>
      <blockquote>
      <p>Instances should be serializable.</p></blockquote>
      <p>I added this</p>
      <blockquote>
      <p>Parsing, normalization, conversion, and formatting function names<br />
      could benefit from sharing common looking names with other locale-related<br />
      classes.</p></blockquote>
      <p>Formatting, Parsing and Normalization will be done by Zend_Locale_Format.<br />
      All locale-related functions will be done by Zend_Locale_Format.</p>
      <blockquote>
      <p>Methods should not combine input parsing, normalization, and output<br />
      formatting all in one step. Instead, parsing and normalization could be<br />
      encapsulated by a constructor. Then a "formatTo($someLocale)" can be<br />
      applied to the instance. This implies that Zend_Currency should yield<br />
      instance objects, and that an internal "normalized" form exists.</p></blockquote>
      <p>Internally only a "value" will be saved. The class itself does not know<br />
      which locale or formatting rules to use.<br />
      By construction Zend_Locale_Format is called to extract the normalized value.<br />
      Also by formatting the output properly the Zend_Locale_Format functions will<br />
      be called.</p>
      <blockquote>
      <p>Most currency formats render similarly to numbers in the same locale,<br />
      often differing only in the number of decimal digits. Obviously,<br />
      redundancy of code in the implementation of locale classes should be avoided.</p></blockquote>
      <p>There will be no redundancy as this functionallity is included and used from<br />
      Zend_Locale_Format.</p>

      <hr />
      <p>I hope I didn't forget something, and all questions are answered as expected.</p>

      1. Jul 19, 2006

        <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Feedback</ac:parameter><ac:rich-text-body>
        <p>Some previous comments were made for reasons of completeness and clarification, and not because something should be changed.</p>

        <p>Regarding the request for a couple examples showing the motivation for creating a separate APIs for currency number formatting and a non-currency number formatting, we are looking for specific examples showing a currency amount that formats differently than the same number in the context of the same locale. All locales we're familiar with (German, Swiss, French, UK, etc.) the number part of the currency formats identically to a simple round of the same amount formatted according to the general rules of formatting that number in that locale. So for the U.S., we have $1,003.10 (one thousand three dollars and 10 cents). In the U.S., the same number (1,003.10) formats identically for length, weight, height, area, volume, mass, etc. The request for an example was for the purpose of demonstrating the need to distinguish between formatting currency numbers and formatting regular, non-currency numbers. I've seen claims that there are some countries where they do not format the same, but I haven't yet found any examples. Interestingly, <a class="external-link" href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Currency.html">http://java.sun.com/j2se/1.5.0/docs/api/java/util/Currency.html</a> does not appear to support distinguishing the formatting of currency amounts and number amounts, other than the number of fraction digits. Are they right or wrong? Examples from the LDML database will offer proof.</p>

        <p>Regarding, "Parsing, normalization, conversion, and formatting function names<br />
        could benefit from sharing common looking names with other locale-related<br />
        classes," the toString() function has the effect of formatting the currency, even though the implementation may reside in Zend_Locale_Format(). Thus, from the perspective of a developer using Zend_Currency, the function toString() formats. However, the locale related classes have inconsistently named top-level API level functions to do parsing, normalization, conversion, and formatting. There is no immediately recognizable consistent convention in the names of the functions of these classes for invoking similar functionality (e.g. output formatting, like toString or toValue) on different types of locale objects. However, we're not requesting specific changes, only suggesting that we look for opportunity to make function names more consistent, when reasonable.</p>

        <p>There is still some debate about whether instances of Zend_Currency should be plain numbers or full objects, although objects allow for easier customization and extension (fits our easy-to-use goal). One recent suggetion we received:</p>

        <ul>
        <li>Imagine a website that auctions items in different countries.</li>
        <li>Consider an adding machine that adds the cost of items in the user's shopping cart.</li>
        <li>Pretend we have an external service available to convert currency amounts.</li>
        <li>Now what code could we write using Zend_Currency to normalize the input data, use the pretend service to convert currencies to a base currency (for the user's locale), and add the results?</li>
        <li>Also interesting to consider using Zend_Currency to format the output table of ammounts, including the total in each of the input ammounts' locales and also the user's locale.</li>
        <li>Additionally, the amount displayed for each of the currencies "foreign" to the user should have the number separators the user is familiar with (e.g. an item costing twelve hundred euros in France would display as "1,200.25 Euros" for US users, but "1.200,25 Euros" for German users).</li>
        </ul>
        </ac:rich-text-body></ac:macro>

        1. Jul 20, 2006

          <blockquote>
          <p>Some previous comments were made for reasons of completeness and clarification, and not because something should be changed.</p></blockquote>
          <p>The few changes I made were nessesary in my eyes, as I reviewed the complete class and also compared with other currency implementations.</p>
          <blockquote>
          <p>Regarding the request for a couple examples showing the motivation for creating a separate APIs for currency number formatting and a non-currency number formatting, we are looking for specific examples showing a currency amount that formats differently than the same number in the context of the same locale. All locales we're familiar with (German, Swiss, French, UK, etc.) the number part of the currency formats identically to a simple round of the same amount formatted according to the general rules of formatting that number in that locale. So for the U.S., we have $1,003.10 (one thousand three dollars and 10 cents). In the U.S., the same number (1,003.10) formats identically for length, weight, height, area, volume, mass, etc. The request for an example was for the purpose of demonstrating the need to distinguish between formatting currency numbers and formatting regular, non-currency numbers. I've seen claims that there are some countries where they do not format the same, but I haven't yet found any examples. Interestingly, <a href="http://java.sun.com/j2se/1.5.0/docs/api/java/util/Currency.html">http://java.sun.com/j2se/1.5.0/docs/api/java/util/Currency.html</a> does not appear to support distinguishing the formatting of currency amounts and number amounts, other than the number of fraction digits. Are they right or wrong? Examples from the LDML database will offer proof.</p></blockquote>
          <p>3 things to mention here.</p>

          <p>First:<br />
          There is always a differnce between CurrencyFormat and DecimalFormat. When looking to LDML you would see CurrencyFormat = '¤ #,##0.00' and NumberFormat '= '#,##0.###'. So the difference is not only the precision but also where to show the currency symbol. In LDML itself you have Formats defined for Currency, DecimalNumber, ScientificNumber, PercentNumber.</p>

          <p>Second:<br />
          Your question for Differences between Number and Currency Formating I found 282 defined currency formats differing from numberformats.<br />
          as_IN - Currency Grouping by 2 - ¤ #,##,##0.00<br />
          ar_xxx and be_BY - Currency Symbol with no space to number - ¤#,##0.00<br />
          bg_BG - Currency Symbol right - #,##0.00 ¤<br />
          de_LU - Currency with NO precision - #,##0 ¤;-#,##0 ¤<br />
          el_GR - Minus Sign befor currency sign - #,##0.00¤;-¤#,##0.00<br />
          en_BE - Minus befor, Currency sign after value - #,##0.00 ¤;-#,##0.00 ¤<br />
          en_POSIX - no grouping - ¤ #0.0<br />
          fa - differences between positive and negative currency - #,##0.00 ¤;'‪'-#,##0.00'‬' ¤</p>

          <p>Third:<br />
          What i'm missing in Java's currency class is the definition or function WHERE to place the currency symbol.<br />
          As we can see in the LDML the currency sign has to be placed different in different locales.<br />
          Also the translated name of the currency is not present. LDML gives us this information also.<br />
          And at last we have not only the sign but also the international short name of a currency present in LDML.<br />
          So we have for example :<br />
          de_DE : Sign - € ShortName - EUR Name - Euro</p>

          <p>Therefor I decided to make an own class for handling currencies correct as shown in LDML inclusive currency sign,<br />
          precision, formatting and so on.</p>
          <blockquote>
          <p>Regarding, "Parsing, normalization, conversion, and formatting function names<br />
          could benefit from sharing common looking names with other locale-related<br />
          classes," the toString() function has the effect of formatting the currency, even though the implementation may reside in Zend_Locale_Format(). Thus, from the perspective of a developer using Zend_Currency, the function toString() formats. However, the locale related classes have inconsistently named top-level API level functions to do parsing, normalization, conversion, and formatting. There is no immediately recognizable consistent convention in the names of the functions of these classes for invoking similar functionality (e.g. output formatting, like toString or toValue) on different types of locale objects. However, we're not requesting specific changes, only suggesting that we look for opportunity to make function names more consistent, when reasonable.</p></blockquote>
          <p>I'm reworking my locale proposals to meet this issue.<br />
          There will be the following locale-independent functions which will be used in every locale-aware class.<br />
          <strong>toValue</strong> - plain number (integer or float)<br />
          <strong>toString</strong> - string conversion with option to convert, change locale and so on.<br />
          <strong>add/sub</strong> - maths with same locale objects<br />
          <strong>compare</strong> - compares two locale objects<br />
          <strong>serialize/unserialize</strong> - serialization of object</p>

          <p>I don't think that I've missed something here, or ?</p>
          <blockquote>
          <p>There is still some debate about whether instances of Zend_Currency should be plain numbers or full objects, although objects allow for easier customization and extension (fits our easy-to-use goal). One recent suggetion we received:</p>

          <p>Imagine a website that auctions items in different countries.<br />
          Consider an adding machine that adds the cost of items in the user's shopping cart.<br />
          Pretend we have an external service available to convert currency amounts.<br />
          Now what code could we write using Zend_Currency to normalize the input data, use the pretend service to convert currencies to a base currency (for the user's locale), and add the results?</p></blockquote>
          <p>Example:</p>
          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          $input1 = '12,345.678 euro';
          $value = new Zend_Service_CurrencyConverter($connect, $input1, 'Euro', 'Dollar'); // Convertion Service from Dollar to Euro
          $item = new Zend_Currency($value,Zend_Currency::DOL); // Get new item value

          $input2 = Zend_DB_ReadValueFromDatabase; // All values in database are stored in dollar - get this value
          $cart = new Zend_Currency($input2,Zend_Currency::DOL); // Get cart value

          $cart->add($item); // Add Item Value to Cart

          echo $cart->toString(); // Output sum value

          // Optionally we could write $item = new Zend_Currency($value); as the currency itself is not needed because
          // $cart defines it's own currency.
          // Adding 2 differenct currencies will throw an exception as there is no convertion service avaiable.
          ]]></ac:plain-text-body></ac:macro>

          <p>So:<br />
          1. get input<br />
          2. get cart<br />
          3. convert 1 or 2<br />
          4. add them<br />
          5. output<br />
          As the user sends his locale with his browser the standard locale for this user is set to his preferred language.</p>

          <p>Of course...<br />
          When someone would write a proposal for an Currency-Convert-Service this would be super-duper-mega whatever. <ac:emoticon ac:name="smile" /><br />
          But as I know all of these convertion websites cost something.</p>
          <blockquote>
          <p>Also interesting to consider using Zend_Currency to format the output table of ammounts, including the total in each of the input ammounts' locales and also the user's locale.</p></blockquote>

          <p>Example:</p>
          <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
          $value = $cart->toValue();
          $converted = Zend_Service_CurrencyConverter($connect, $value, 'DOLLAR', 'EURO'); // Convert value to wished currency

          $region = Zend_Currency::getRegionForCurrency('JPY'); // Get Region for Currency
          $output = new Zend_Currency($converted, Zend_Currency::EUR, $region); // Regions-locale aware currency f.e. japan
          echo $output->toString(); // Outputs eur in japanese locale
          ]]></ac:plain-text-body></ac:macro>

          <p>1. get value - 1234<br />
          2. convert it to wished currency - 1400<br />
          3. get region for this currency - JP<br />
          4. create currency object with converted value and wished region - 1400 euro display in japanese formatting rules<br />
          5. output - 14,00.000 eur for example</p>

          <p>To mention:<br />
          The locale is used for the formatting rules, and where to place the currency symbol<br />
          The currency is used for knowing the currency symbol or name.</p>
          <blockquote>
          <p>Additionally, the amount displayed for each of the currencies "foreign" to the user should have the number separators the user is familiar with (e.g. an item costing twelve hundred euros in France would display as "1,200.25 Euros" for US users, but "1.200,25 Euros" for German users).</p></blockquote>
          <p>Therefor the locale parameter was added.<br />
          Each locale defines how to format a currency.<br />
          There is not a definition per currency but per locale.</p>

          <p>So a user of de_LU will see:<br />
          14.000,00 EUR<br />
          and a user of the region en will see:<br />
          EUR14,000.00</p>

          <p>But when overriding the locale we can produce an output for a complete new locale.</p>

          1. Jul 25, 2006

            <p>Looks good to me!</p>

            <p>Notes:</p>

            <p>The "add/sub" functions for currency will meet some resistance, as some believe math should be performed external to the class, using getters/setters (or some might argue currency values shouldn't be objects). Again, the simplest way to convince people is using example use cases that are simpler than required by other, alternative implementations (i.e. not including add/sub functions for Zend_Currency).</p>

            <p>The "format the output table of ammounts" example was meant to highlight that some people will object to creating individual objects for a big table full of currency amounts. However, I think your examples show that Zend_Currency is extremely simple and easy to use <ac:emoticon ac:name="smile" /></p>

            1. Jul 25, 2006

              <p>Good to hear <ac:emoticon ac:name="laugh" /><br />
              I will add some "simple" examples to the docu.</p>

              <p>One idea I've had:<br />
              Maybe it makes sense to implement an "interface" for the conversion of currency. So someone could write a Service Class which grabs the actual conversion from a bank web-site and transport the conversion unit to Zend_Currency.</p>

              <p>So we would not provide a real conversion between Currencies for now, but maybe in the future <ac:emoticon ac:name="wink" /></p>

              1. Jul 31, 2006

                <p>If a conversion-interface service proposal was designed to work with real-world SOA/web services provided by real companies, then I expect a similar classification and prioritization to the other Zend_Service* proposals. Andi has spoken in favor of these for several good reasons.</p>

                1. Jul 31, 2006

                  <p>I expect this should be read as YES to my idea. <ac:emoticon ac:name="wink" /></p>

                  <p>But is it a "YES... immediately"<br />
                  or is it a "YES... a little bit later when this class works for all other proposed issues" ?</p>