PrimArray pointers

[Mark S. Miller <mark>]

Date: Sat, 15 Dec 90 18:37:59 PST
   From: michael (Michael McClary)

   ... 

(further ...'s not explicitly shown below when between blocks)

   First, what is to replace the functionality?  In a glance through the
   .hxx file I saw no member function other than operator[] that was an
   obvious candidate for extracting or storing values at a particular
   offset.  Arrays without any sort of subscription seem somewhat futile
   even if steppers ARE available, so if there is no alternate subscription
   operation I suspect we'll need to write one.

I would replace it with two named member functions perhaps named 
"void store(UInt4, T)" and "T fetch(UInt4)" where "T" is the type that
we have an PrimArray of (Heaper */SPTR(Heaper), UInt1, UInt4,
IntegerVar).  These messages aren't polymorphic with the ones in
MuTable, but they can be understood as closely analogous to those.
Our X++/febe developers will also have to be familiar with MuTable's
protocol. 

   Second, isn't this a problem ONLY for people writing directly in C++?
   Doesn't smalltalk always generate the right thing when you use at: or
   at:put:?  Won't you have to rehack the translator to make it generate
   the replacement?

It's worse than that.  One has to be able to deal with primitive C
arrays from Smalltalk as well.  Since the translator doesn't know the
type of the receiver, the *apprpriate* sends of at: and at:put: would
have to be changed by hand.  I volunteer to do this when I have the
time.

   As I read it, the confusion is the result of thinking of the variable
   which is a pointer to the object as the object itself, and naming it
   accordingly.  This is the normal smalltalk idiom, but it's one I avoid
   like the plague that it is.

Depends whether one is focused on composition of services, or
composition of storage.

   The confusion is made total by what I consider the REAL bug:  The existence
   of an operator[] in special overridings of SPTR and CKPTR (but not WPTR!).

Agreed.  It is the operator[] in the pointer types that really
motivated all this.  I don't feel at all strongly about the operator[]
in the Heapers (though I'd still like to remove them, see below).

   (BTW:  This
   overloading appears broken under opaque definition of the Array classes,

Good point!  I didn't notice that.

	   PtrArray * arrayP = somePtrArray;
		   // (But aren't bare "XanaduObject *"s considered poor form,
		   //  one of the things XLint checks for, and about to be made
		   //  unnecessary by the *PTRs-to-everything trick?  If so,
		   //  any code of the sort in this chunk, if it exists, can
		   //  soon disappear.  Unfortunately, WPTRs are still typedefed
		   //  as "Whatever *"s - but making them full-blown classes
		   //  with no virtual member functions should just eliminate
		   //  the undesired case while leaving the code generated for
		   //  the remaining cases unchanged.)

We can't turn WPTRs into full blown PtrVar classes, because we use
them in places where PtrVar classes won't work--because C++ doesn't
provide the ability to define PtrVar classes that coerce the way *
pointers do.  

	   Heaper * anObj = (*arrayP)[1];
		   // The pointer must be dereferenced to pass operator[] to the
		   // array itself, but this is now obvious from the name.

Yes, this works, and does what someone who is thinking "C" real hard
may expect.  However, I find it confusing despite 10 years or so
experience with C.  The question I would ask is: is it substantially
less confusing to a C whiz (who already has to deal with MuTables
anyway) than:  	   Heaper * anObj = arrayP->fetch(1);  ?

   Unless someone has a better idea, I'd (moderately) favor:

    - removing the broken []-forwarder from SPTRs and CKPTRs (which can be
      done by stripping out the special overridings, replacing them with
      the normal macros expansion).

Yes!  As long as this done, I'm happy.  The rest is just icing.

    - checking that the smalltalk translator and the Array-using code
      (if any) in xpp/ do the right thing,

A pain, but I already volunteered above.

    - perhaps renaming some variables (if the variable-name business strikes
      anyone as a brilliant idea rather than compulsive pickyness - which
      I doubt will happen among native speakers of Smalltalk).

Even before I ever touched a Smalltalk-like language I would avoid
this.  It makes the same mistake Bliss makes: putting the notational
burden on the common case (1 level of indirection) instead of the
wierd one (0 levels of indirection).  I'd be much happier with a
suggestion that we suffix all non-pointers with "Var".  (Not happy,
just happier).

   Though all choices
   are bad here, I suspect we'll help them more if we give them an environment
   with a pitfall they're used to avoiding than if we eliminate the hazard by
   substituting something extra for them to learn.

I think C pointer indexing is so confusing that most C programmers
avoid pointers to arrays.  In any case, because of the MuTable
similarity, my alternative isn't really much extra to learn.

How's about it?