Yes, I understand that, and I even understand the purpose of GENERIC.
I simply wanted to explain what we do. Maybe it is important to know that we
have other languages (ASSEMBLER, C) as well, so we need solutions which work in
all languages. And, what seems most important to me:
a) I don't want the callers to have to change their calls (which is the same
as with the GENERIC approach)
b) and: I don't want to have the program logic in more than one place
(which is also possible with the GENERIC approach, if some of the
three procedures call each other)
The drawback of not using GENERIC: I have to inform the callers that they have
to use DIFFERENT names, depending on their need regarding the parameters. But I
do it this way: the variant with the maximum parameter count is the only one
which will be supported in the future, and the others are only supported for a
limited time frame for convenience of the existing callers. So every resonable
developer will switch to the variant that I want to support in the long term.
Am 16.02.2013 10:56, schrieb R.V.:
> From: Bernd Oppolzer Sent: Saturday, 16 February 2013 8:45 PM
>> I don't know much about GENERIC, but to your original problem:
>> I would suggest writing a new procedure with a new name, which
>> supports the
>> additional CHAR parameter, copying all the code from the old one.
>> And then you replace the old procedure by a new one which simply calls
>> the new procedure and specifies a default value for the new CHAR
> P. has a family of three procedures, with one, two, and three arguments,
> The existing procedure supports one argument. Two new ones are to be written,
> supporting two and three arguments, respectively.
> Am 15.02.2013 14:17, schrieb P.H.:
>>> Did you try "DEFINE STRUCTURE"and use the type name in the GENERIC
>> No. But I happy with
>> dcl SetDSError GENERIC (
>> SetDSError0 when ( * ),
>> SetDSError1 when ( *, char ),
>> SetDSError2 when ( *, char, char )
>> The compiler complains as expected when argument and parameter
>> types/structures do not match.