[Prev][Next][Index][Thread]
Re: A NAM Veteran muses ...
On Thu, 24 Feb 2000, Hugh Greene wrote:
> Having been thinking about various Dylany things recently, the following
> language extension idea popped into my head the other day ...
> ...
> define implemented domain my-gf (<string>);
>
> which would disallow remove-method on the domain, while still allowing
> add-method (and methods added by "define method")?
>
>
> I haven't thought this through, but points to be addressed include:
>
> 1) Would this actually provide the compiler with enough information to
> give a useful list of definite NAMs at compile time? ...
Oops -- I also meant to say that a compiler would report an error for
"implemented" domains for which no methods were provided "at compile
time". This is because, although the compiler might not find any calls to
the GF in this domain, which would cause NAMs, such calls might be
constructed dynamically or in a client library, beyond the reach of the
compiler's analysis.
This is another reason why my point 2 about "at compile time" is tricky.
You could defer the check until the start of runtime, allowing
"implemented" domains to be satisfied by methods in other libraries which
are part of your app. Or you could flag a library as being the "root"
library for an application, in which case you could do the check "at
compile time" of the root library, rather than the one defining the GF.
Maybe this could be called a "sideways implemented" GF?! This means you
don't get the extra definite-NAM information when you compile the
GF-defining library but you do at least get it before you run your app.
Hmm ...
Hugh
Follow-Ups:
References: