[Quantlib-dev] Re: Decoration of Handles in ObjectHandlerXL

[eric e. <eri...@gm...>]

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 <eri...@gm...> 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.