ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

OVERLOADing

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • OVERLOADing

    Am I missing something? If I have a procedure called VectorAdd and at some later date I decide I want to overload it to a new 'VectorAdd' with different parameters, I now have to rename the orignial procedure to something else because otherwise I get a duplicate name. Renaming it will obviously force me to recompile everything that is currently using my Service Program so I really want to avoid that, but I can't see how to get around this. What have other people done in similar situations? Is there a cunning work-around?

    Just to be clear. if I have this:

    VectorAdd(@Vector:@NewElement) ;

    and I decide I want to have a new procedure which accepts another parameter, like this:

    VectorAdd(@Vector:Index:@NewElement) ;

    I can't use overloading to do that without renaming the original VectorAdd procedure, correct?

  • #2
    Here's an article that can help you, Ray.

    The ability to overload subprocedures in RPG is something I had been waiting for a long, long time. IBM finally made it available through a Technology Refresh (7.4, TR1 or 7.3 TR7). If you are not familiar with the term, overloading (in RPG) is the ability to create multiple subprocedures of the same name with

    Comment


    • #3
      Thanks Ted. I've read quite a few examples like that but it doesnt help. The answer to my question, I think, is "no you can't do that" and that makes me sad

      Comment


      • #4
        My question is why are you creating the new procedure with a different parameter sequence? The "natural" way to handle this would be to add the new parm as the last one with Options(*NoPass) and modify the original subproc to use %ParmNum and %Parms to determine which way to do the processing.

        I think though that you could probably get away with using overload but I won't get into the details until you tell me why the "better" solution isn't!

        Comment


        • #5
          Yes, obviously I could use *NOPASS in this example - but it's just an example! It could be *any* new parameter list, right? The principle remains. If you have a solution, please tell.

          Comment


          • #6
            Something like this:

            Code:
            dcl-pr vnew;
              x char(1);
            end-pr;
            
            dcl-pr v;
            end-pr;
            
            dcl-pr vo  overload( V: Vnew );
            I don't think it is a good idea but if it was essential to avoid recompiling it should work.

            The original is v. That is the exported name and will continue to work just fine - in fact the name isn't even used after the CRTPGM so ... BUT you would have to use binder language to make sure the slot number associated with v didn't change if re-creating the service program containing v and vnew.

            Subsequently next time you touched a program that used v you should update it to call vo - new code uses vo from the outset.

            To me it probably creates more work than it saves.

            Comment


            • #7
              Thanks Jon. I think you’re right - more bother than it’s worth ☹️

              Comment


              • #8
                An SQL function can be created to receive different parameters for different functionality within the same SQL function. But you're right, RPG procedures can't be overloaded as far as I know.

                Comment


                • #9
                  Well I gave up and decided to concentrate on making my life easier instead - a command that scans a source file and automatically detects and renames 'duplicate' procedures, then updates the file (and its /COPY file) to include an OVERLOAD block that utilises the renamed procedures. So although I can't avoid renaming the overloaded procedures, at least I don't have to do it manually anymore.

                  Comment

                  Working...
                  X