Re: (elementary question) Test on type ?

[Ted Dennison<dennison@telepath.com>]

In article <3b95eca7.5408987@news.demon.co.uk>, John McCabe says...
>
>I don't know whether you missed the original message, but it
>contained:
>
>> Assume:
>>  
>>  
>> -- specification :
>> generic
>>   type T is (<>);
>> function F(X : T) return Float;

Ahh, you're right; I did miss that.


This issue does actually come once in a while too, when you've got code that
needs to be mostly the same, except for one little bit. I think you pretty much
have to hack it. Approaches I have seen:

Make one generic for each type.
Variant 1: Copy and pase the code (maintainence problems).
Variant 2: Use a common subprogram for the common code (cool, but only works if
you don't need to use the generic part in the common code).

Make one generic, hack the difference.
Hack 1: Make the user supply a boolean designating which code path to take.
(flag coupling - fairly bad)
Hack 2: Make the user supply the non-common code themselves as a procedure
parameter. (works well if the non-common stuff can be put together, and it
doesn't rely on package-internal stuff, and you can trust the clients to get
this code right. Not so good if its stuff the clients shouldn't have to worry
about doing themselves.


Hack 1 is really just a special case of Hack 2, where the routine being supplied
is an "Is_Integer" routine, simplified to a boolean. Somewhere in between these
two extremes you may find a good spot.

---
T.E.D.    homepage   - http://www.telepath.com/dennison/Ted/TED.html
          home email - mailto:dennison@telepath.com