🚀 go-pugleaf

In article <4700042@ada-uts> richw@ada-uts writes:
>
>>>  Simply put it gives you the ability to dynamically bind actions
>>>  without the invoker of the procedure having to know about the
>>>  procedure being called.
>
>So does the enumeration-to-procedure mapping method I proposed.
>
>>>                         ...  The use of enumerated types does no
>>>  good and there are no real good solutions that I know of in ADA
>
>I'm sorry, but I simply fail to see how your examples provide
>conclusive arguments that this method will not work in general.
>GRANTED, the mapping method is less convenient for the programmer,
>but my point was that it is nevertheless possible in Ada at a
>reasonable expense (which I think is justifiable given that omitting
>procedure pointers from Ada prevented Ada from becoming even more
>complex).
>
        I fail to see how an enumeration can solve the general
problem(even given your example). Given that at the time you write the
mapper package you do *not* know what procedures will be called by it,
and that *most* of the procedures to be used do not even exist yet,
*how* can you create an enumeration type that covers the set? The
whole point of function pointers as arguments is that it allows the
writing of *generic* procedures which can be "customized" by the
individual user by providing a pointer to a user supplied routine,
this allows the general routine to be used on data structures or
views that were not anticipated when the original routine was
written. If you can explain how to access non-existant functions,
whose names you do not even know, using an enumeration mapper, then I
will I will admit that this is equivalent to function pointers.
--

                                Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ??