× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Hi Doug,

You are correct that until qualified data structures, an opcode like EVALC
wouldn't make sense.  But until externally-described files and the PREFIX
keyword on F-specs or Data Structures, hardcoded field name prefixes were
(IMO) a necessity. Now we have some flexibility, which is not to say that
it's not still a good idea, especially since we have slightly longer field
names, just that it's not so much of a necessity.

I have run across programs that used the same field names for the disk and
display files, so I do recognize that it's not a "necessity", but with that
style program it's a bit harder to keep track of where a field's value came
from, especially when you didn't write it.

Regards,
Peter Dow
Dow Software Services, Inc.
909 793-9050 voice
909 522-3214 cellular
909 793-4480 fax


----- Original Message -----
From: "Douglas Handy" <dhandy1@bellsouth.net>
Sent: Wednesday, August 21, 2002 6:13 PM
Subject: Re: Same prefixes (was Re: It's That Time Again! etc.)


> >This was generally considered a good idea way back in the days of yore
(i.e.
> >before externally-defined files),
>
> Although I did in fact start this practice before the S/38 existed, why do
> externally described files change whether it is a good idea?  The problem
is
> name collissions in RPG, and until qualified DS names that was true in all
> flavors of RPG.
>
> Qualified DS names makes for a more elegant solution, but how do external
> definitions vs program described files weaken the argument for field name
> prefixes?
>
> Am I not seeing the forest for the trees?
>
> Doug





As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.