Re: Assignment between strong pointers

[<eric@son-of-blob>]

From: mark@xxxxxxxxxxx (Mark S. Miller)
	Subject: Assignment between strong pointers
	
	Does the compiler like the following alternates for cases #1 and #2?
	Even if it does, these alternates are worse than case #3.  However, if
	this works maybe perhaps it will lead to something else that works.
	
	
	1')	PTR(Foo) func (PTR(Bar) barP) {
			return (PTR(Foo)) barP;
		}
	
	2')	PTR(Foo) func (PTR(Bar) barP) {
			PTR(Foo) fooP = (PTR(Foo)) barP;
			return fooP;
		}
	
The compiler does take the two cases above, and I'm also of the opinion that
they are worse than my original case (3) which doesn't explicitly use cast
operators.

	What if we add a 
	
	    LEAF operator SUPERTYPE * ();
	
	where SUPERTYPE is the declared immediate superclass of TYPE?  Does
	this help any of the cases?  (If it does, then our HIDDEN_CLASS macro
	may be in trouble.

The main problem with this case comes when one is concerned with
SUPERSUPER...TYPE.  If the compiler can't figure out neighboring types, we
can't expect it to be able to figure out more distant relations.
	
	Isn't it amazing how empirical one has to be with what are claimed to
	be formal systems?

The language may be defined formally (*cough* *cough*), but implementations of
things tend to be empirical beasts (at least in the rest of the world :-) )	
	Overall, my impression is that our source code in C++ is going to
	start looking rather awkward (not simply as a result of the above, but
	cumulatively from all the little problems).  This makes developing in
	Smalltalk that much more attractive (keep the source clean; hide cruft
	in the translator).  Unfortunately some of us are stuck for a while.
	
The thought of having the translator take care of this stuff for the Smalltalk
stuff has been a major factor that has allowed me to sleep at night while
adding all this apparently necessary cruft to the language.  Unfortunately,
there are probably people in the outside world who aren't going to want to
use Smalltalk.

	- e -