|
Evan Harris wrote:
But as I said in my other email, searching was not the primary reason for having it at the bottom of the list in the case I mentioned.
Hi, Evan. I'm not clear on what that reason was. The main item that I saw was: "The only argument with any merit at all I have ever heard for putting QTEMP at the bottom of the library list was that this made it more difficult to accidentally access a copy or subset of a production object and made it more obvious that a copy or override of an object in QTEMP was being used by virtu of the hard coding."But if that's the reason, then why have QTEMP in *LIBL? Remove QTEMP and there won't be any significant chance of accidentally hitting something in QTEMP. The duplicate would only be accessed by explicit qualification or override. So why have QTEMP in *LIBL if that's the reason?
If users have the ability to make copies, they can make them into QTEMP regardless of position. But if QTEMP isn't in *LIBL, the copy won't be mistaken for the original unless an override is in effect (or explicit qualification). And if overrides (or qualification) are allowed, then again position isn't relevant -- nor is existence in *LIBL.
As for it being more obvious, it still would only be accessed by override or qualification if QTEMP was at the bottom. And neither of those need QTEMP in *LIBL. The obviousness of override or qualification remains the same when QTEMP is not in *LIBL.
No? Tom Liotta
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.
midrange.com
