http://quantlib.414.s1.nabble.com/Decoration-of-Handles-in-ObjectHandlerXL-tp11090p11095.html
Your scenario of yieldCurve updating... Not bad.
updating of the curve without the reconstruction of it. Most implementations
Okay I agree that you need the user key for this scenario. But I'd certainly
(in BOLD!!!). This would be for advanced users of Excel who know all about
>That's with cell references. The problem arises when you retrieve an
>object via a raw string "my_object". In this case you have no
>From: "eric ehlers" <
[hidden email]>
>To: "Toyin Akin" <
[hidden email]>
>CC:
[hidden email]
>Subject: Re: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL
>Date: Mon, 24 Apr 2006 13:08:37 +0200
>
>Hi Toy,
>
>From your message it's not clear to me whether you're responding to my
>original proposal (20 April) or the revised one (24 April).
>
>Let me reiterate that under the revised proposal, the existing
>behavior of OH would be retained. The user would additionally have
>the option of retrieving objects via handle stubs.
>
>On 4/24/06, Toyin Akin <
[hidden email]> wrote:
> > I don't like the idea of the user being able to use the stub key if a
>unique
> > key is generated for him/her and this new key provides no chances of
> > mispricing on the sheet (assuming that all input parameters are correct
>and
> > the user knows the instrument they are pricing).
>
>Under the revised proposal, OH supports retrieval of objects both by
>the handle stub ("my_object") and the full handle
>("my_object~_xxxxx"). Normally objects would be retrieved by their
>full handle but if required the user has the option of retrieving an
>object by its stub - in which case the user must respect the caveat
>that Excel no longer forces the object to be refreshed before it is
>referenced.
>
>If you feel that allowing this alternative behavior is dangerous then
>we could consider making the behavior configurable - you could build
>OH such that retrieval of objects via the handle stub is not supported
>(i.e. preserve the current behavior).
>
> > As your library grows and many more objects are added, using the stub
>only
> > approach makes it difficult to track unique objects.
>
>Under the proposed approach OH throws an exception if a user attempts
>to retrieve an object via its handle stub and two objects exists with
>the same stub.
>
> > Why not stick with the "my_object~_xxxxx" key?
>
>For normal use yes.
>
>We have a special case where we'd like to support retrieval of objects
>via the stub. Consider three sheets which
>1) instantiate some rate helper objects (qlDepositRateHelper)
>2) update the rates in real time (qlSetQuote)
>3) bootstrap the yield curve (qlPiecewiseFlatForward)
>
>Now imagine that we have multiple versions of #2 depending on where we
>want to source the rates feed. When we bootstrap the yield curve, we
>don't want to bother about which sheet is updating the rates. Here's
>what we do:
>
>- Load sheet #1, refresh it, and close it.
>- The OH repository is now initialized with a collection of rate
>helper objects ("ON", "1W", "1M", etc.)
>- The sheet which created these objects (#1) is closed, so the objects
>will not be reconstructed again
>- Load sheets #2 and #3. The curve is bootstrapped, the rates are
>updated in real time, and the state of the curve changes accordingly
>(thanks to QL's behind-the-scenes use of the Observer/Observable
>pattern)
>- Note that no further deconstruction/reconstruction of objects is
>taking place - we are merely changing the state of the rate helper and
>yield curve objects, which were constructed once
>
>If we have to use full handles, then sheet #3 needs to know which
>version of sheet #2 is in use. This could change from one session to
>the next. Maintaining this link is not impossible but we find it more
>convenient to allow objects to be referenced via handle stubs. Sheets
>#2 and #3 simply trust that rate helper objects ("ON", "1W", "1M",
>etc.) exist without needing to know their full handles. Therefore
>sheet #3 doesn't need to link to sheet #2 and we can switch to a
>different version of sheet #2 without editing sheet #3.
>
> > Also using the stub key only where the object may have already have been
> > created (a yieldcurve and a book object with the same name) would cause
> > errors on the spreadsheet that will be very difficult to track down.
> >
> > The result will simply display #value, but for the user, how do you
>debug
> > this?
> >
> > Visiting dependant cells may not help, because the previous object with
>the
> > same name may have been created within another pricing calculation
> > (worksheet/workbook same Excel session).
>
>Suppose the user tries to create two objects, and supplies the same
>stub, "my_object", to both constructors. This will succeed, exactly
>as it does today - the first object will be created e.g. as
>"my_object~_00001" and the second as "my_object~_00002".If the user
>requests "my_object~_00001" or "my_object~_00002" he gets the correct
>object back. If he requests "my_object", OH sees that two objects
>exist with that handle stub and throws an exception.
>
> > What are the main issues in not using the computed key?
>
>As discussed - normally we use the computed key. But when we want to
>reference an object and don't want to keep track of where in the Excel
>session it resides - we reference it via the handle stub.
>
> > Also, the "stub" key is static and Excel will not detect a change within
> > it's calculation dependency list. One will have to resort to a global
>(F9)
> > spreadsheet computation in order to ensure any new changes to the key is
> > picked up (that's assuming the previously created object is not part of
>this
> > updating too!!)
>
>I was under the same impression, until Plamen clarified things for me.
>
>Consider two cells, A1 which constructs an object, and A2 which
>references the object in A1.
>
>Under the design proposed on 20 April, A1 would hold value "my_object".
>
>Since Excel 2003, changes in A1 would still force a recalc of A2.
>When the inputs to A1 change, Excel is smart enough to realize that
>the dependents of A1 need to be recalculated, even though the physical
>contents of A1 are unchanged.
>
>That's with cell references. The problem arises when you retrieve an
>object via a raw string "my_object". In this case you have no
>guarantee that you're getting the latest version of "my_object".
>
>Anyway under the revised design, the existing behavior of OH is
>preserved, and cell A1 contains "my_object~_xxxxx". Normally A2 holds
>a reference to A1. But in the special case described above we also
>have the option for A2 to refer to the raw string ""my_object". In
>this case the user must ensure that a refresh of A1 is followed by a
>refresh of A2. As mentioned in our environment we accomplish this by
>putting A1 on a separate sheet and closing the sheet after the object
>is instantiated.
>
> > Just my 2 cents worth...
>
>I very much welcome your feedback.
>
>Regards,
>Eric