when to type an object as pointer

4.1: 4.2: adda/dstr/pointer/when to type object as pointer:
implicit conversions:
. in designing syntax, it's been assumed that explicit is good,
hence we encourage the explicit use of pointers;
but that idea is at tension with trying to avoid
unnecessary implementation details .

. there should be implicit conversion routines
for the assignments between a value
and a pointer to an object of compatible type .
. assignments like (v.t`= p/.t )
-- where a value of type t is assigned a
pointer to value of type t --
should be converted to ( v`= p/ ),
and (p/.t`= v.t ) should be converted to
( p=nil? p`= new-local-space; p/`= v ).
[4.7:
... but we need a way to take aliases:
( p`= v) should always take the address of v
-- even if v is a literal,
v has a location (to read-only template memory);
but p can't point to it unless p is of a compatible type
(pointer to read-only);
or,
any pointers should be variant records
whose discriminant is always keeping track of
whether the object being pointed to is rom or not;
or,
pointers should always point into the symbol table,
and then the symbol table gives both the address
(as a stack offset) and the obj's type .]

. it has been assumed at one point
that even if a var is typed as a non-pointer,
part of polymorphism should include accepting either of
{a value, pointer to value, function pointer to value};
but, when is this needed?
pointers can save space by sharing an immutable,
but only when the type is larger than a pointer .
. on the other hand, having everything be a pointer
can double the space needed by many math programs .
. if we can be sure that the pointer is a constant,
we can make the address part of the function's template,
(as a constant offset of the current stack pointer)
so then the address can be shared by
every activation of a function .
. instead of making this polymorphism a pervasive feature,
the compiler can, as an optimization,
statically type certain a symbol as {value, pointer}.

. does the oop object's implicit self parameter
need to be a pointer, or can it be a value?
. other oop-supporting lang's have situations where
the self obj's address seems to be needed;
but when is this really needed
(and not just an impl' choice)?
. the type mgt should be able to specify
whether an object needs to be a pointer .
[4.29:
. I was confusing is-a-pointer with
is a pointer-to-pointer;
of course it has to be a pointer; because,
it's an inout parameter;
even if you're doing copy-in-copy-out,
you still need a pointer to copy-out to .
. the choice that oop implementations make
is what the self parameter is the address to:
# a value,
# a pointer to value .
. if you have an address to the value's pointer,
then your type mgt can modify not only the value,
but also the subsequent location of the new value .
. so the answer I was looking for originally is
"(no:
an equivalent alternative to changing self's location,
is to have self's memory size be expandable
so there is never any need to change the location;
you simply overwrite the current location,
and extend the memory if you run out of room) .]