Re: To Initialise or not

[Ken Garlington <garlingtonke@lmtas.lmco.com>]

Robert A Duff wrote:
> 
> Here's a real practical example, which might be more convincing than
> vague notions of readability:
> 
> I have a program that uses access types.  I want to convert to using
> integers, where the integers point into an array.  There are several
> reasons you might want to do that.  E.g. if you know you only have a
> small number of heap objects, you might be able to make the integer
> smaller than an access value.  It might make it easier to manage your
> heap in some way that is not directly supported for access types.
> 
> If you followed the convention of always explicitly initializing access
> types (either to null or to whatever the right value should be), then
> this conversion can be fairly mechanical -- change "Foo.all" to
> "Heap(Foo)", where Heap is the array representing the heap.  Change
> "null" to "Null_Pointer", where Null_Pointer is a constant initialized
> to an integer number representing null, and so on.

I thought I was convinced by this, but on reflection...

1. Are you converting _all_ access types to encoded integers, or just a
particular _use_ of an access type? If the latter, then you can't do it completely
mechanically (assuming more than one access type) for all occurences of null.
You still have to find the specific declarations that need to be modified. Since you
have to do that anyway, you're really not gaining much by denoting them with an 
explicit null. Now, if you had a different name for null for each access type, this 
might work. Otherwise, I don't think you gain very much.

2. Assuming you really _are_ converting all access types to integers (or even
if you're not, now that I think about it), you have a different problem. To retain
your (presumably desired) behavior of an implicit null being used to catch errors,
you also have to come up with some way to trap references to your uninitialized 
integers. This means you have to visit those declarations with the implicit null,
and either assign them an out-of-range value (Null_Pointer, maybe?), or do something 
else. (You probably will also want to add the appropriate assertions in your code 
before you "dereference" the integers. However, even if you didn't add the code, the 
Null_Pointer assignment would still be useful for debugging purposes...)

3. Both of these actions (replacing the explicit null with Null_Pointer, and the 
implicit null with... Null_Pointer?!?) can be done mechanically (and with less human 
error, I suspect), without the explicit null - assuming you have a tool that does data 
flow analysis, or at least can track declaration/use information. In fact, the explicit 
null could actually reduce the effectiveness of such an analysis. I know that, 
particularly with older code that has been maintained by several parties, I would trust 
an automated analysis tool over your coding convention.

So, I'm still not convinced.

> 
> - Bob

-- 
LMTAS - "Our Brand Means Quality"