> the code. If they are placed in resource/text files
> code. Of course that gives rise to some additional
This approach would suggest XML documents. Which means
possibly the deal types too. This would mean a
myself ... and nicely buzzword compliant as you could
>
> Andre/Luigi
>
> I am new to QuantLib so I haven't looked at this in
> detail but at first glance I had similar thoughts to
> Andre.
>
> Andre, correct me if I'm wrong, but I think you are
> talking about what I would call "static data". That
> is any data type which may change (albeit not
> regularly) and for that reason it should be used by
> the code but not form part of the code. Things like
> currencies, holidays, countries and trading
> locations should not really be hard-coded. I doubt
> that any robust system would deal with these by hard
> coding the variables BUT in an open source library
> what type of database could be used; Oracle, Sybase,
> SQL Server, Interbase? There are just too many
> options with different advantages and disadvantages.
> For an open source library you have to make static
> data available without limiting the user to any
> particular technology or platform.
>
> One other solution I can think of it to apply the
> Java approach of making these items "resources" of
> the code. If they are placed in resource/text files
> they could be stored with the code but not in the
> code. Of course that gives rise to some additional
> coding effort such as text parsing and manipulation.
> Any other thoughts?
>
> Rgds
> Rod
>
>
> ---------------------------------------- Message
> History ----------------------------------------
>
>
> From: Luigi Ballabio
> <
[hidden email]>@lists.sourceforge.net on
> 10/04/2002 10:13 CET
>
> DELEGATED - Sent by:
>
[hidden email]
>
>
> To: Andre Louw <
[hidden email]>;
> "QuantlibUsers (E-mail)"
> <
[hidden email]>
> cc:
> Subject: Re: [Quantlib-users] Persistancy
>
>
> At 09:41 AM 4/10/02 +0200, Andre Louw wrote:
> >I have a quick question on persistancy. The way you
> handle persistancy on a
> >specific Calendar is via code (e.g
> johannesburg.cpp). Do you have a seperate
> >layer that handles it in a different way (file,
> database etc...) in your own
> >use of QuantLib? I'm tickled on how you could have
> generic code that prices
> >an instrument on different Calendars without such a
> layer?
>
> Hi Andre,
> I'm afraid I didn't get the question, but
> then again, I still
> haven't had my coffee this morning. What do you mean
> by "persistancy on a
> Calendar"?
> I recognize both words, but I fail to see the
> connection.
>
> Later,
> Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
>
[hidden email]
>
>
>
>
> --
>
> This e-mail may contain confidential and/or
> privileged information. If you are not the intended
> recipient (or have received this e-mail in error)
> please notify the sender immediately and destroy
> this e-mail. Any unauthorized copying, disclosure or
> distribution of the material in this e-mail is
> strictly forbidden.
>
>
>
> _______________________________________________
> Quantlib-users mailing list
>
[hidden email]
>