Re: [Quantlib-dev] Any rationale that currency codes and calendars are hard coded at compile time rather than read from a text file at runtime?

[R Y <fan...@gm...>]

Your points are perfectly valid. My point is that reading from a text file
improves the extendibility of the library as it doesn't require rebuilding
the source code (of course I'm sure you're well aware of that). And for date
format we can easily require that the text file be encoded in utf-8 and the
date in yyyy-mm-dd ISO format.
Cheers.
On Mon, Oct 3, 2011 at 6:42 PM, Luigi Ballabio <lui...@gm...>wrote:

> On Sun, 2011-10-02 at 09:08 +0800, R Yan wrote:
> > And would it benefit at all if someone contributes a module that reads
> > currency codes and calendars at runtime?
>
> As for calendars, the rationale is having rules (for example, "each 25
> december" or "the third Wednesday in October") that remain valid for
> each year, instead of having to generate and distribute the data files.
> The possibility of creating a calendar at runtime is given by the
> BespokeCalendar class, whose instances take a list of dates (to be read
> from a file or otherwise) and build the corresponding calendar.  I'd
> leave out the part where one reads the file, especially since it depends
> on locales (today's date is written as 03/10/2011 in Italy and
> 10/03/2011 in the US).
>
> For currencies, you might add a constructor to the Currency class that
> takes the needed data and thus instantiates a currency at runtime.
> Again, I'd prefer to leave out the "read from a text file" part (or from
> a database, or from any other source) that can be done easily by any
> application using the library.
>
> Luigi
>
>
> --
>
> Never mistake motion for action.
> -- Ernest Hemingway
>
>
>