David,

>From: "Haas, David" <david.haas_at_owenscorning.com>
>Subject: RE: Not a value
>
>Tom, thanks for the suggestion. The 'addr' operator does seems to clear up
>the compile problem.
>
>I note, however, that the documentation (reference manual section 10.1.2)
>seems to be pretty explicit that referencing the object instance to get its
>address, without requiring a method, is valid usage, as in:
>
>POINT BUILDS ORIGIN
>ORIGIN 2 CELLS DUMP

The reference manual, as are most things in the world of software,
is a work in progress.

Executing the name of an object does indeed push the object's address
onto the stack. However, there is a global side-effect: the search order
is modified to include the members list (so that members of the object
can be found and executed appropriately). This would be fine, except that
the word DUMP is a member of the SUPREME class, and by default all classes.
So, to do the exact thing you were attempting to do

ORIGIN DUMP

would suffice. The parse and execute of DUMP will clear up the search order
and leave you where you expect to be.

To confuse the matter,

ORIGIN 2@ . .

would work quite nicely too, since the object ORIGIN left its address on
the stack. But note that the side-effect (changing the search order) was
not done, and the search order is still set to find and execute a member
of ORIGIN, and will stay that way until a member is found. BUT, (and this
is the big BUT) since each member expects the object address to be on the
stack when it executes, and you took the address of ORIGIN off the stack
with the 2@ . . , things will likely crash here.

I don't know an easy way to explain all that, but I hope this helps.

Rick

.
Received on Mon Nov 22 1999 - 09:11:11 PST