|
> From: Jeff Crosby > > > Buck wrote: > > > For some reason I can't put into words, I find this... distasteful. > > I agree with that sentiment. What's the difference between that and > LVLCHK(*NO)? This is the same thing, to me, as adding fields at the end > of a file, then creating the file with LVLCHK(*NO). Remember, I am about as clueless here as they get, but let me make a comment. While I agree that a hardcoded signature is sort of like LVLCHK(*NO), it's more like an intelligent LVLCHK(*NO). Let's carry the analogy forward. This is LVLCHK(*NO) when you know all the original fields are the same and you're only adding fields to the end of the record. Now, if I had applications that read a file, and I knew that the record format was the same and that those applications had no need for the new fields, I'd be fine with LVLCHK(*NO). What Barbara is suggesting (I think!) is that the old fields (e.g., the old procedures) are not changing, and that older programs aren't using the new fields (procedures). Well, to my mind that makes sense. The only time you'd have to change the signature is if the interface to one of the existing procedures actually did change. And then you'd for sure want to recompile every program that uses that procedure. This makes lots of sens to me. It's kind of like the signature identifies whether the interface has CHANGED. Having new things added does not change the interface, it simply extends it. And in fact, in an OO environment, if you add things to your interface, you shouldn't have to recompile objects that talk to you, as long as you satisfy all the old requirements. Now, it would be nice if the signatures were a little finer grained - one master signature at the highest level, and then individual signatures for each procedure. Then a program could check the master signature, and if it didn't match, could check the individual signatures for the procedures it uses. If those all matched, then it could just continue on. But that's a different issue for a different day.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.