Re: renames and access

["Robert I. Eachus" <rieachus@comcast.net>]

Francesco Bochicchio wrote:

> I thought of that:
> 
> 1. It adds a function call overhead for each time one of the variables is
>    accessed ( and it happens a lot )

It does NOT add function call overhead, especially if you in-line the 
function.  What it does do is insist that the names be re-evaluated when 
used.  To the extent that this is what you wish, you get what you asked 
for.  If you can use a grosser level of granularity, you can put some 
sections of code in a handler that just reinvokes the code, and have the 
code use local renames.

> 2. It only solves variable reading. I don't see any equivalent way to
> assign values to the variables.

Huh?  A function that returns an access type can appear as part of a 
name on the left hand side of an assignment statement.  So if you have a 
function A that returns a pointer to an object with components C,D and E 
of type Integer,

A.E := 3;

works just fine.

What you might have to do is a global replace on the code to change 
current instances of E to A.E assuming A and B are record containing the 
data that you want replicated.  Notice that a renaming of A.E as E will 
"lock in" the current dereference.  You can combine it with what I said 
above about granularity, and if the retries occur at a high enough level 
you won't have to change much.  (All you have to do is put all renames 
inside the code that is retried after a failure.)

There is no easy way to do the analysis needed to decide how far out you 
can move the retries in various areas of the code.  But once you do 
that, renamings should work fine.

-- 
                                           Robert I. Eachus

"The war on terror is a different kind of war, waged capture by capture, 
cell by cell, and victory by victory. Our security is assured by our 
perseverance and by our sure belief in the success of liberty." -- 
George W. Bush