RE: Re: Decoration of Handles in ObjectHandlerXL

Posted by Toyin Akin on Apr 24, 2006; 3:43am
URL: http://quantlib.414.s1.nabble.com/Decoration-of-Handles-in-ObjectHandlerXL-tp11090p11093.html

Hi Eric,

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).

As your library grows and many more objects are added, using the stub only
approach makes it difficult to track unique objects.

Why not stick with the "my_object~_xxxxx" key?

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).

What are the main issues in not using the computed key?

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!!)

Just my 2 cents worth...

Toy out.

>From: "eric ehlers" <[hidden email]>
>To: "QuantLib developers" <[hidden email]>
>Subject: [Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL
>Date: Mon, 24 Apr 2006 08:54:40 +0200
>
>Hello,
>
>Plamen pointed out to me that the change below breaks dependency
>tracking where the user supplies the handle as a literal string
>(rather than a cell reference).  So I rolled back that change,
>apologies for the confusion.
>
>I propose instead a solution which preserves existing behavior while
>additionally allowing the user to refer to objects by the handle stub:
>
>- user creates object and supplies stub "my_object"
>- OH suffixes stub with unique key returning "my_object~_xxxxx" to calling
>cell
>- user may later ask for either "my_object" or "my_object~_xxxxx" and
>OH is intelligent enough to always retrieve "my_object~_xxxxx"
>
>If the user refers to an object by its stub then dependency tracking
>is not enforced and the user is responsible for ensuring that the
>referenced object is refreshed before it is requested.
>
>Also the handle stub is not guaranteed to be unique.  When the user
>refers to an object by the stub then OH checks whether multiple
>objects exist with the same identifier and if so an exception is
>thrown.
>
>Please get back to me with any thoughts or concerns.  I hope to
>proceed shortly with the implementation.
>
>Regards,
>Eric
>
>On 4/20/06, eric ehlers <[hidden email]> wrote:
> > Hi All
> >
> > Problems have arisen with the ObjectHandler feature of decorating
> > object handles e.g. "my_object" -> "my_object_~xxxxx" and in CVS I've
> > disabled this feature.  Garbage collection continues to function as
> > before but the user is now responsible for guaranteeing that his
> > handles are unique.
> >
> > If this causes problems please let me know.  Please see below if you
> > require further detail.
> >
> > Many Thanks,
> > Eric
> >
> >
> > The user supplies a stub "my_object" and gets back "my_object_~xxxxx"
> > where xxxxx is a unique key used to link back to the calling cell for
> > purposes of garbage collection.    xxxxx gets incremented every time
> > the object is reconstructed.
> >
> > Suppose the user wants to pass that object to another function. If he
> > just references the cell containing the object e.g. A3 then all is
> > well.  But suppose a reference to the calling cell isn't convenient.
> > The user knows he called his object "my_object" and wants to use that
> > handle but can't because the object is now called "my_object_~xxxxx".
> >
> > The example presented to me is where we might use one of several
> > different workbooks to create rate helpers e.g. "1W", "1M", ... We
> > want to bootstrap the yield curve without worrying about which book
> > was used to create the helpers so we want to refer to the rate helpers
> > by their raw handles not by referencing the cell in which the rate
> > helper object resides.
> >
> > In CVS I've commented out the old behavior and replaced it with a
> > tentative implementation of the new approach.  The "~xxxxx" is
> > retained internally for garbage collection which continues to function
> > as before but the user doesn't see this and is now responsible for
> > ensuring that his handles are unique (as has always been the case when
> > GC is disabled).  Longer term I would make some further refinements to
> > the new code I just want to make sure this change won't cause problems
> > for anyone.
>
>
>-------------------------------------------------------
>Using Tomcat but need to do more? Need to support web services, security?
>Get stuff done quickly with pre-integrated technology to make your job
>easier
>Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
><a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
>_______________________________________________
>Quantlib-dev mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev