Re: [QuantLib-svn] SF.net SVN: quantlib:[16174] trunk/QuantLib

[Luigi Ballabio]

On Thu, 2009-04-16 at 14:56 +0000, [hidden email] wrote:
> Revision: 16174
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=16174&view=rev
> Author:   nando
>
> Log Message:
> -----------
> - added static Event::hasOccurredFunction to encapsulate the hasOccurred logic to be used also by non-Event object

If it's generic logic, it shouldn't be in the Event class, even as a
static method.  Then again, if you want to use it somewhere else, it's
probably a sign that something else should be inherited from Event and
is currently missing.


> - modified Event:Date() to return a const reference

This doesn't give you anything (allocating a reference is just as costly
as allocating a Date on the stack, since Date only contains a long. Any
number of methods doesn't make a class any more heavier to instantiate)
and forces any Event class to store the date, thus preventing it from
calculating the date on the fly.


In short, I'd revert the whole changeset, at least until we think a bit
more about it.  Objections?

Luigi


--

Perfection is reached, not when there is no longer anything to add, but
when there is no longer anything to take away.
-- Antoine de Saint-Exupery



------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Ferdinando Ametrano-4]

Hi Luigi

>> - modified Event:Date() to return a const reference
>
> This doesn't give you anything [..] and forces any Event class to store
> the date, thus preventing it from calculating the date on the fly.
Agreed. It escaped me. I can revert it tomorrow

>> - added static Event::hasOccurredFunction to encapsulate the hasOccurred logic to be used also by non-Event object
>
> If it's generic logic, it shouldn't be in the Event class, even as a
> static method.
Agreed again. I put it there just because the Event class
documentation suggest that it should be the only place in the code
that is affected directly by QL_TODAYS_PAYMENTS.
I could take it out of the Event class and keep it in the same
event.hpp file, or put it in its own file, as you prefer

> Then again, if you want to use it somewhere else, it's
> probably a sign that something else should be inherited from Event and
> is currently missing.
Agreed again, anyway it would require a lot of refactoring and I'm
currently not up for it.
The goal of this commit was to uniform the hasOccurred logic which was
erratic for non-Event object, and I would keep this result.

ciao -- Nando

------------------------------------------------------------------------------
Stay on top of everything new and different, both inside and
around Java (TM) technology - register by April 22, and save
$200 on the JavaOne (SM) conference, June 2-5, 2009, San Francisco.
300 plus technical and hands-on sessions. Register today.
Use priority code J9JMT32. http://p.sf.net/sfu/p
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev