|
> From: Simon Coulter > > Bad idea for a number of reasons. Most of which are opinions (with which I disagree). > 1) The only reason you get away with it is because the code is > in-house. Yep. API sales. This one matters to people who sell APIs. > 2) Consumers only need the prototypes. They have no business looking at > the implementation in a properly designed interface. If I'm debugging, I had better be able to see the source code of the modules I'm calling. > 3) If someone forgets the proper DEFINE they get the source copied into > the program leading to all manner of peculiar behaviour: If someone forgets a semicolon in /free, they get all kinds of peculiar behavior. If someone forgets the "F" in an F-spec, they get all kinds of peculiar behavior. > 4) It's just plain ugly to require the consumer to decide whether they > want the code or not. Eye of the beholder. Personally, I LIKE the fact that all my prototype includes are nicely encapsulated inside a /DEFINE PROTOTYPE and a /UNDEFINE PROTOYPE. > /copy rpgleinc,fbnmath > /copy rpgleinc,fbnstring > /copy rpgleinc,fbndate > > is much cleaner than forcing the consumer to remember to code > /define prototypes > /copy rpgleinc,fbnmath > /copy rpgleinc,fbnstring > /copy rpgleinc,fbndate > /undefine prototypes "much cleaner"? How? > 5) Having a separate define for each prototype name is even uglier. Not sure who brought this up. Not me. On the other hand, there are real reasons to use the /DEFINE PROTOTYPE method. I may want to define an area in the caller and not in the callee. That area may need a predefined layout, such as a data structure. With the use of the /DEFINE, the source member can define the data structure in both places as based, but actually define data for it in the caller: D MyParmDS s based(pMyParmDS) (...) DS Subfield definitions D MyProcedure PR D pDS * /IF DEFINED(PROTOTYPE) DwMyParmDS s like(MyParmDS) DpMyParmDS s * inz(%addr(wMyParmDS)) /EOF /ENDIF In the single include technique, I'd have to hand-code those last two lines. Two lines may not be much, but it gets more involved with more complex structures. Whether you like this technique or dislike it, it can only be done with a single include member. Joe
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.