Re: Var is dead! Long Live CheckedPtrVar and IntegerVar!

[Michael McClary <michael>]

> From: vlad!mark (Mark S. Miller)
> 
> Until now, we never did follow through the logical implications of the
> Var vs Heaper distinction--largely because we didn't realize until
> recently what those logical implication were.  Vars are objects which
> are allocated on the stack, as data members (instance variables), or
> as global variables.  They are passed by value, and their exact type
> is always statically known at compile time (an implication of being
> passed by value).  They overload operators like crazy, and attempt to
> act like some kind of basic C data type.  []

They have another property:  They must have a fixed set of possible
values, regardless of the platform.  We must decide now, for all time,
whether they are four-byte twos-complement binary numbers (or equivalent),
or what.

This happens because they carry no flavoring that would allow them to
be of arbitrary size, yet they:
 - Participate in code which must have identical behavior regardless
   of the platform's archetecture.
 - May be members of objects whose execution spans platforms of varying
   archetectures.
 - Are encoded in formats that cross platforms on comm links or
   removable media.
Each of these might be worked around separately, but the first two
would require enormous effort.

> This has all gone away simply by creating a new overloading of
> Xcvr::send and Xcvr::receive for IntegerVars.  Now a Xcvr client can
> deal with the transmission and reception of IntegerVars with the same
> notation that he would use for any other integral type.

Oops!  Did I say I didn't have the bert on Xcvrs?   If so I mispoke
something fierce.

I intended to have dropped the bert only on things specific to remote
procedure calls.  Changes to CommXcvr I need to be aware of.  But this
is a change to Xcvr.  SnarfXcvrs (on which I have the bert with a vengance)
inherit from Xcvr, and must track this change.

This is not to say "don't do it".  I just want to be sure you're aware
we'll need to merge on anything comm-related that isn't specific to RPC.

	michael