Var is dead! Long Live CheckedPtrVar and IntegerVar!

[Mark S. Miller <vlad!mark>]

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.  Heapers are of course
exactly the opposite (sort of).  Adding new types of Heapers is
considered to be normal programming.  Adding new kinds of Var is to
extend X++ itself.  

Having made this separation, I then proceeded to idiotically create a
class Var to be a subclass of Tofu & a superclass of all Var-style
classes.  What we came to appreciate over time was:

If we always knew their exact type at compile time, then they needed
no run-time polymorphism.  If they were going to be used to imitate C
data types (e.g. IntegerVars and CheckedPtrVars), then they would be
used in a sufficiently frequent & lightweight way that the normally
cheap vtable pointer would be expensive.

In the new scheme, class "Var" is no more.  CheckedPtrVar has already
successfully been made into a root class with no vtable by Mr. Hill.
At this moment I'm doing likewise to IntegerVar.  It is no longer an
anamoly(sp) that CheckedPtrVars and IntegerVars are Vars, while
BooleanVars, IEEEDoubleVars, and StrongPtrVars are not Vars.  Now they
are all Vars, but there is no class Var.  What it means to be a Var is
to satisfy the above properties.

There's only one problem with this, which I'm now repairing.  The one
place where we broke with our conventions for Var use was in the Xcvr
classes.  We had generic methods for sending and receiving Vars.  To
get around the "pass-by-value implies compile time type" on the
sending side we used references.  Yeech.  To get around it on the
receiving side we actually heap allocated a copy of the var, and then
"memcpy"d it into the storage for the actual Var (thereby violating
the object's right to manage it's own storage).  Double yeech.

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.

The cost of all this is that, as we add new Var types to X++, we will
have to manually extend all the Xcvr classes to cope.  As such an
addition constitutes an extention of the X++ language, this doesn't
seem too great a burden.

(Actually, once we have the abstract-signature-to-message-handler
generation tool mentioned in previous mail messages, I have some ideas
about how to have this particular cake and eat it too.  But that can
wait for another time.)