Posted by
Simon Ibbotson - Straumur on
URL: http://quantlib.414.s1.nabble.com/Non-copyable-curves-tp12013p12018.html
Okay, that makes sense. I'll implement copy-constructors for the
interpolated curves (I've got several more changes to contribute, so I
may as well make them all consistent).
Regarding "good behaviour" for development in quantitative libraries, in
the past I've worked in small development teams (up to 15 people) where
there were minimal restrictions on what a developer can/can't do:
namely, the code should compile and the test application should not fail
any tests (of course, bug fixes should never break an interface).
This method isn't perfect (by any means) but with this method, if a user
wishes to use new released functionality, it then becomes the
responsibility of them to integrate any interface changes for a new
release. Alternatively, they can get involved in the development process
and ensure that any interface changes can easily be incorporated into
their external applications.
Is there any documentation on "good practise" for QuantLib / open-source
development? Freezing an interface (at the C++ level during the
development cycle) would mean allowing only incremental additions to the
header files... is that the intention for QuantLib? Alternatively, do we
have a set of classes which form a fixed interface, behind which the
implementation structure (all other classes) can change?
All advice welcome.
Simon
-----Original Message-----
From: Luigi Ballabio [mailto:
[hidden email]]
Sent: 18 April 2008 09:31
To: Simon Ibbotson - Straumur
Cc: op;
[hidden email]
Subject: Re: [Quantlib-dev] Non copyable curves.
On Thu, 2008-04-17 at 17:14 +0000, Simon Ibbotson wrote:
> This change has occurred on \trunk, the library still compiles and it
> doesn't break any of the test-suite, so it meets all requirements that
> I would have for a multi-developer library.
>
> If you need a frozen user interface - use a published release instead.
No, Ole is right---interfaces shouldn't break between releases.
Unfortunately, as we're nearing 1.0, we became aware of a few bad design
choices we made earlier. Correcting those will break something, but we
think that the resulting design will make up for the inconvenience.
After 1.0, the interfaces will be frozen.
As for this particular change:
> My concern is that - as someone trying to contribute to the library -
> a rather restrictive ban on copying curves has been introduced.
This was not based on some design principle. Simply, I suddenly noticed
that copying behavior for interpolated curves was broken---if you copied
an interpolated curve, the interpolation inside the copy would still
point to the data in the original curve. As a quick safety measure, I
disabled copying; a full solution which I haven't had the time to
implement would be to implement the correct copy constructors. We'll
have to do that before release (and, Simon, feel free to go ahead if you
want,) at which point the broken code would work again as before. No, on
second thought, not as before---it would work correctly...
Luigi
--
Present to inform, not to impress; if you inform, you will impress.
-- Fred Brooks
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev