Message-Id: <9210062238.AA02941@Athena.MIT.EDU>
To: aybee@Athena.MIT.EDU, wjeuerle@Athena.MIT.EDU
Cc: jud@ithake.MIT.EDU
Subject: Name conflict and other issues
Date: Tue, 06 Oct 92 18:40:54 -0400
From: Judson Harward <jud%ithake@ceci.mit.edu>

	When you have time -- no rush.

	Since you didn't like Pointer, I thought I would call that critter
an identifier, but then i realized that the lexical entities used to name
functions and variables are usually called identifiers.  I spoke with Phil and
suggested either Reference or Handle as an alternative for the generalized
pointer base type.  Phil didn't like Reference because of its specialized
meaning in C++.  He was worried by Handle because it has a special meaning on
the Mac, and, I gather, also under Windows.  Still, it seemed the better
option.  How do you feel about calling the generalized pointer base type a
Handle?

	Comments.  I can live with using C++ style comments.  Sigh.  The hard
part will come when we read ADL code in, edit it using an AM2 editor, and write
it back out.  I have to come to grips with this when I describe the Scribe
object.  OK.  First we need to decide what we want to happen, and then
whether we are clever enough to do it.  It would be a pity to just throw away
comments the way AM1 does now.  Sooo, what about saying that we would throw
away any // comments, but that any /**/ comments would be saved and would
appear at the start of their enclosing scope in any AM2 generated output.
If we were really clever, I suppose we might try to associated any // comments
with the immediately preceding statement, but I just want to blow them away.

	Finally, on calling C++ methods of system defined objects from ADL
code, what about something like the following:

	class aSystemClass
	{
		public:
			RetType aMethod(ArgType1 arg1, ...);
			void aMethodFromADL(void *retVal, void **argVec);
	}

	aSystemClass::aMethodFromADL(void *retVal, void **argVec)
	{
		ArgType1 arg1 = *((ArgType1 *)(*argVec++));
		   .
		   .
		   .
		Either
		   aMethod(ArgType1 arg1, ...);
		Or
		   *(RetType *)retVal = aMethod(ArgType1 arg1, ...);
	}

	A static class member function would need to register all the
methodsFromADL functions with the ADL message dispatcher at startup along
with their expected argument types and return values.  I think we could
automate the creation of the methodsFromADL functions from their corresponding
method declarations using a yacc script.  We could then use such a utility as
part of the make process.  All methodsFromADL would be defined in a separate
.C generated as part of the make process.

	Yes, it is ugly, but is it worth at least pursuing?  More elegant
approaches.

						Jud