Re: Problem with instantiating generic procedure

[Tucker Taft <stt@averstar.com>]

Markus Kuhn wrote:
> ...
> 
> What is wrong with simply implementing a procedure declared
> in the spec file in the body file by instantiating it from
> a generic procedure of the exact same signature? Both A and G
> have no parameters, so how can there be a conflict?

We considered allowing a subprogram spec to be completed by
a generic instantiation during the 9X design process.  Ultimately
we chose to only allow renaming-as-body.  So if you want to do
this, you must first do the instantiation using a different name,
and then define the body by renaming this generic.

The rationale behind disallowing a generic instance to be used
directly was as follows:

   A generic instantiation does not include any parameter profile
   for the subprogram being defined.  Hence, matching it up with
   a spec in the presence of overloading could be difficult for the
   reader.  On the other hand, a renaming includes a parameter profile.
   Hence, matching a spec with a renaming-as-body did not impose any
   extra burden on the reader.  Therefore, given the general preference
   for readability over writability, renaming-as-body was proposed as
   the general solution to problems like this, and instantiation-as-body
   was not allowed.

That's the rationale.  I will admit we had a fair amount of discussion
before we came to consensus.  It is always tricky to negotiate these
readability versus writability issues.  In the long run the emphasis
on readability always seems wise, but in the short term, the emphasis
sometimes comes across as just being arbitrarily picky.

> ...
> 
> Any idea what is wrong here?

You need to use renaming-as-body instead.
> 
> Markus
> 
> --
> Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK
> Email: mkuhn at acm.org,  WWW: <http://www.cl.cam.ac.uk/~mgk25/>

-- 
-Tucker Taft   stt@averstar.com   http://www.averstar.com/~stt/
Technical Director, Distributed IT Solutions  (www.averstar.com/tools)
AverStar (formerly Intermetrics, Inc.)   Burlington, MA  USA