🚀 go-pugleaf

In article <1992Jul23.024159.18039@microsoft.com>, Jim Adcock writes:
> This would require some understanding and memory retention of my prior
> statements on your part so that I do not have to keep repeatedly answering
> your same mistakes made over and over again.

I wonder if it ever occurred to you that the explanation for my
continuing to maintain my objections is that we disagree about the
validity of your arguments, rather than that I have forgotten them or
didn't understand them in the first place?


> |	i		Fetch the value at the appropriate offset in
> |			f()'s stack frame
> 
> Plain Wrong.  The expression "i" at this location means "reference to the object
> named by i".  Your interpretation is simply in error, as can be seen
> by using your expression "i" as follows:
> 
> 	i = 5;

But that wasn't the expression I was explaining.  Implicit in my
explanation was an "rvalue" context, which I used because I thought it
would be clearer; in retrospect, I suppose that I should have written
"i;" to avoid any confusion.  However, following your suggestion and
using the more general "reference to..." phraseology does not change
the point I was making -- that the "." simply supplies the
qualification needed to interpret what follows it.

Let me recast the table in a way that I hope will avoid any confusion
about lvalues versus rvalues:

expr		addressing context	scope
----		------------------	-----
i		stack frame of f()	f()

::i		program static		file
		storage

x.i		x			class X

(*xp).i		object to which xp	class X
		points (indirection)

xp->i		object to which xp	class X
		points (indirection)

xr.i		object to which xr	class X
		refers (may not be
		an indirection,
		depending on
		implementation)

In each case, you look up the name "i" in the implied scope, take the
corresponding offset out of the symbol table, and add it to the base
address implied by the addressing context.  Whether you use the
resulting address in an lvalue or rvalue context is immaterial to the
process.  The role of "." is simply to indicate that the expression
preceding the "." is to be used to determine the addressing context
and scope for the interpretation of the name following.  This is
exactly analogous to what "::" and the absence of qualification do.

> |	x.i		Fetch the value at the appropriate offset in
> |			the object "x"
> 
> Plain Wrong.  The expression "x.i" at this location means "reference to the 
> object named by 'x.i'".

This isn't detailed enough.  Using your terminology, it should read,
"reference to the object named 'i' within the object 'x'", which is
consistent with my explanation above.

> On the contrary, if your phrases above were correct, you would find
> that in all cases an indirection occurs.  Its just that in some built-in
> cases the compiler is smart enough to commonly optimize out the indirection.

Just out of curiosity, did you ever program in Bliss?  If I recall
correctly, it has this idea that every name is really just a pointer.

> Your statement is false.  One 
> DOES NOT have to provide forwarding functions for those features of the 
> target class one desires to use.  On the Contrary one can CHOOSE to provide
> forwarding functions if desired.

If the target class has a member operator and you want to use it via
the smart reference, you MUST provide a forwarding function under your
proposal.  Neither your operator.() nor the conversion function
alleviates this necessity.  If you "CHOOSE" not to provide such
forwarding functions, the desired operations simply won't be available
via the smart reference.  I agree that you have reduced the burden of
writing forwarding functions in your proposal, but you have not
eliminated it.

> Your statement is false again.  No circumlocution is necessary because
> of "implied this."  Correct your errors and your objection does not stand.

No circumlocution is needed in the smart reference's member functions,
agreed, but that was not the context I was describing.  If there is a
"metaoperation" to be performed on the smart reference itself, the
circumlocation *is* necessary.  Such metaoperations might include
status queries, cache invalidation, network rerouting, etc.

> You also need to explore my proposal, so that you can discover that in
> fact the particular disadvantages you mention are not in fact disadvantages
> of my proposal, but rather errors in understanding on your part.

I have explored your proposal.  The three disadvantages are still
there.  Refusing to acknowledge them doesn't make them go away.  There
is room for discussion about the degree to which they are significant,
but denial doesn't move that discussion forward very much.

-- William M. Miller, wmm@world.std.com