Re: Module source naming schemes

Okay.  So now I am going to have four functions.
RcvNetF(UserName, SysName) where UserName and SysName will be *NoPass
RNF_Open(UserName, SysName) which will simply call RcvNetF passing the 
parameters
RNF_Read() which will simply all RcvNetF passing no parameters
RNF_Close() which will, currently, do absolutely nothing.

I don't have to do this at this time, I could put the actual processing
into the subroutines, but I'm used to doing things this way.  The theory
being that RNF_Open, RNF_Read and RNF_Close will never change in the parameters
they are accepting, but RcvNetF may change at any given time depending on
how I find the best way to do things in the future.

Which brings up a question.  I build this all into my modules.  I link my
modules into my service program. I link my service programs into my Bound
Library.  Then I go and change RcvNetF, and the way it interacts with my
other calls in the same module.  When I recompile my module, do I have to
relink it to my service program?  And then do I have to relink my service
programs into my bound library?  And then do I have to recompile all the 
programs that use the bound directory?

Regards,

Jim Langston

Scott Klement wrote:
> 
> On Tue, 9 Jan 2001, Jim Langston wrote:
> 
> > Scott,
> >
> > Yeah, I'm not happy with the 'F' 'N' and 'C' myself.  I am contemplating,
> > and probably will, go into the //copy member for this and create some 
>constants.
> > RNF_Open 'F'
> > RNF_Next 'N'
> > RNF_Close 'C'
> >
> > One thing I have found irritating when I code this is that I only need the
> > first two parameters when I first call this thing.  And every other time I
> > actually don't need any parameters at all if used from a first to last 
>situation,
> > and I really don't even think I have to set on LR for this thing, since it's
> > in activation group *Caller anyway.  And if you wanted a new set and passed 
>it
> > the 'F' again it would resetup the pointers.
> 
> Thats why I make them seperate procedure calls, the parameters that you
> need to "start the list" are rarely the same parms that you need when
> "getting each entry".   I'd use rnf_open, rnf_read and rnf_close.   I
> use this system mainly because all programmers are familiar with the
> open/read/close concept -- so they see it as "easy to incorporate".
> 
> Even if you don't need a "close" right now, I've found that its a good
> idea to have the procedure, and tell programmers to call it.   The reason
> is because even if you don't need it now, eventually -- as your program
> gets changed/improved -- you'll have things that need to be done at
> "cleanup time".   When that happens, you'll be happy that you've already
> got a procedure thats being called by all the programs that use your
> service program...
> 
> >
> > So, all I really need to know is if it's the first time or not, and if
> > it is the first time, what the username and system name are.  Hmm..
> > perhaps 2 calls then.
> >
> > RtvNetFIni(UserName, SysName)
> > RtvNetFNxt()
> >
> > The question then becomes, how do I define my variables so that both
> > RtvNetFIni and RtvNetF can see them?  I am thinking if I declare them
> > at the top of the source file outside any functions they will be
> > global to that source file, and any module contained in it, right?
> > But not visible to other programs, such as the RPG program.
> >
> > Is this correct?
> 
> Yes, this is correct.  (Unless you do an "activation group export", which
> I always discourage people from using)
> 
> > In which case, since they are global, I would want to define them as
> > RNF_Data
> > RNF_Options
> > RNF_Lib
> > RNF_Idx
> >
> > My naming scheme for global variables (ones seen outside one program
> > or function) is three letters designating the function they are from,
> > and underscore and their name.
> >
> 
> Hmmmm...  I personally use this system (the function designation, followed
> by the var name) for variables/constants/functions that are available from
> "outside of the service program", rather than "outside of a function".
> 
> I use "wk" ("work") as a prefix to a variable name for variables that are
> global to my module, but do not affect anythng outside of it, and I use
> "ww" (which, I guess, stands for "workwork"... but ww is just easy to
> type) for variables that are local to a subprocedure.  I also use a "pe"
> prefix for parameters... etc, etc.
> 
> In your case, if I had named constants like error numbers, or something,
> I'd start THOSE with RNF_ and put them in the header...
> 
> Of course, that's just how I'd do it, for informational purposes only.  :)
> I wish you luck on developing a standard that makes sense to you.
> 
> +---
> | This is the RPG/400 Mailing List!
> | To submit a new message, send your mail to RPG400-L@midrange.com.
> | To subscribe to this list send email to RPG400-L-SUB@midrange.com.
> | To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator: david@midrange.com
> +---
+---
| This is the RPG/400 Mailing List!
| To submit a new message, send your mail to RPG400-L@midrange.com.
| To subscribe to this list send email to RPG400-L-SUB@midrange.com.
| To unsubscribe from this list send email to RPG400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---