M. Lazarus wrote:
What I'm saying is that unless there is a really good reason to roll
your own *and* a solid way to ensure that the signature gets changed
when the exports change, let the system generate the unique value for you.
I understand what you're saying here, and what you're saying has merit.
On the other hand, in what, 10 years? I haven't come across much in the
way of protection with the system generated signatures. Here's why.
The overwhelming majority of my changes to a service program, far and
away, consist of adding a new exported procedure. Sure, I could use
EXPORT(*ALL) and let the system generate a new signature for me, but
that would require me to recompile every client program, despite
absolute 100% certainty that none of them have been affected by this
change.
I can think of only one case when the system generated signature would
have helped me, and that's when I accidentally deleted an export. In
the event, the client program rolled over and died because there was a
gross parameter mismatch.
I suppose that there's a window of horrible opportunity for a deleted
export to slip through (no signature violation because of my signature
naming) and the client program consumes the wrong procedure because the
parameters are 'close enough.' In that case, a signature violation
would alert me to the problem before the code executes.
I think the general objection is that the chance of encountering this
sort of snafu is much lower than the certainty of having to recompile
all my client programs when I know full well they don't need it.
--buck
midrange.com
