sponsored links

Collapse

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.

    https://www.itjungle.com/2020/10/05/...subprocedures/

    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