how to or could I ? - Forum - OpenEdge General - Progress Community
 Forum

how to or could I ?

This question is answered

11.7

I have a report like this:

def var bOpen as log no-undo.

for each event:

  iNumDays = getNumberOfDays(output bOpen).

  put ...... iNumDays bOpen.

end.

function getNumberOfDays Returns integer (output obOpen as log):

def var iNumDays as int no-undo.  

find first bEvent where bEvent.field = Event.field 

:

bOpen = if condition....

iNumDays = ......

Return iNumDays.

end function.

Question: Should I use output parameter in a function, or should I 

  make a class and use property/Methods or procedure With output parameters ?

I now understand that I can use output in a function :-)

Verified Answer
  • the function return value of number of days seems like just the right thing.

    making a class with a method to do the same thing is just more work and more complicated.

    for some things, functions are /exactly/ the thing to use.

All Replies
  • the function return value of number of days seems like just the right thing.

    making a class with a method to do the same thing is just more work and more complicated.

    for some things, functions are /exactly/ the thing to use.

  • Thanks Gus, Nice to know :-)

  • I personally see functions with output parameters as code smell, I think a function is to be used for simple calculation using input parameter(s) to return one result and I expect there will be no other side effects. If you want to ‘do something’ use a procedure, if you have too many parameters then you might be doing too much in that code block, if really need more parameters use the ‘parameter object’ (if you don’t use OO a temp-table/dataset can work very well).

    Now, you really should consider passing whatever the function needs as input parameters and don’t rely on global scope… that’s far more important than choosing between a function with output parameters and a procedure or some other OO construct :)

       
    Marian Edu

    Acorn IT 
    +40 740 036 212

  • User Defined Functions are a bit like OO methods in the sense the signature is checked at compile time, as opposed to procedures that give bad surprises at runtime.  Therefore, I tend to favour functions as much as possible in old .p's when one cannot move to OO for maintenance sake**

    As consequence, I don't mind dealing with a function with multiple output params, however I do not like to mix the return value and output params.  Since a UDF cannot be defined as VOID, for the case of multiple output params, I would do the old trick of defining the UDF as LOGICAL, and not return anything.

    **one important difference between a UDF and a procedure : the later can natively hold a transaction whereas a UDF does not, but one can still define a transaction block explicitly in his UDF

  • Hahaha, you mean like this ’strongly type’ compile time check?

    FUNCTION test RETURNS CHARACTER (OUTPUT prm AS CHARACTER):
        prm = STRING(TODAY).

        RETURN prm.
    END FUNCTION.

    DEF VAR prm AS CHARACTER INITIAL 'toto'.

    MESSAGE test(prm) SKIP prm VIEW-AS ALERT-BOX.

    The fact that the compiler doesn’t do the same compile time parameter check for procedures (even for internal ones) still doesn’t make it right… otherwise everyone will use only functions to avoid runtime surprises :)  


    Marian Edu

    Acorn IT 
    +40 740 036 212

  • At my previous client we had a programming standard that explicitly prohibited the use of output parameters on functions. This was done to keep the code as simple as possible; programming is hard enough already without the use of 'clever' tricks. If you need more than one value, use a procedure.

  • Fully agree. Keep it simple is great.
     
    “If you need more than one value, use a procedure.”
    However here, we can also return an object from the function to return multiple related values.
     
    Von: Patrick Tingen [mailto:bounce-ptingen@community.progress.com]
    Gesendet: Donnerstag, 15. Februar 2018 10:48
    An: TU.OE.General@community.progress.com
    Betreff: RE: [Technical Users - OE General] how to or could I ?
     
    /cfs-file/__key/communityserver-discussions-components-files/26/4520.image001.png
    Update from Progress Community
    /cfs-file/__key/communityserver-discussions-components-files/26/4338.image002.jpg
     

    At my previous client we had a programming standard that explicitly prohibited the use of output parameters on functions. This was done to keep the code as simple as possible; programming is hard enough already without the use of 'clever' tricks. If you need more than one value, use a procedure.

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Das Bild wurde vom Absender entfernt.
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Returning one single data object to hold multiple values is the old Java way.  Often some boiling code with classes that bring little value to the business.

    I finally appreciate the new C# way that lets you define multiple out params for simple scalar parameters.

    In that sense, the Progress ABL was ahead of its time.  Why not using it?

    Procedures, Methods, UDF, all those are routines.  UDF and Methods have many advantages over procedures :

    -strong typing for a return value

    -signature check at compile time

    -completion in the editor

    -MUCH FASTER than a proc because no need to check existence of the routine and the signature at runtime (that was done at compile time)

    -more standard for new developers

  • Sebastian, having structured code (not to mention ‘correctly’ formatted) often brings little value to the business :)

    The thing with multiple output parameters is, for me at least, a clear indication your UDF is probably doing more than it should… mind you I’m perfectly ok with the old Java way, that object can be a generic collection or maybe just a ’structured’ object like json object/array.

    No one said you should not use functions though, albeit much of what you name as advantages over procedures could pretty much be fixed by PSC at least for internal procedures… external procedures, those ran in super (including functions) can be excused ;)

    Using routines with multiple parameters might become a pain later on, changing the signature of the routine is not always an easy task… guess a trip to the dark side (javascript) may break any strongly type developer :D

      
    Marian Edu

    Acorn IT 
    +40 740 036 212

  • marian.edu
    guess a trip to the dark side (javascript) may break any strongly type developer :D

    Return of the Jedi: TypeScript! (sorry, couldn't resist).

  • Bronco, you probably refer to that crybaby luke skywalker… Darth Vader don’t need any compiler to check his code, he just know it’s right and no one dare to challenge that ;)
     


  • Until they blew up the Death Star because of some very hard to find omission Geeked 

    This is getting nowhere :-)

  • New C# way? C# has out and ref parameters since over 15 years now. But also objects to be returned. If you look at the majority of C# apis, that return more than a simple or already existing object, they return a specialized object.
     
    The business value: easier to read and maintain code.
     
    You’ve never been in the situation where you had to add an additional output parameter to a procedure or function? A pure nightmare. But a piece of cake with an object.
    Von: slacroixak [mailto:bounce-slacroixak@community.progress.com]
    Gesendet: Donne
    rstag, 15. Februar 2018 12:59
    An: TU.OE.General@community.progress.com
    Betreff: RE: [Technical Users - OE General] how to or could I ?
     
    /cfs-file/__key/communityserver-discussions-components-files/26/6378.image001.png
    Update from Progress Community
    /cfs-file/__key/communityserver-discussions-components-files/26/5543.image002.png
     

    Returning one single data object to hold multiple values is the old Java way.  Often some boiling code with classes that bring little value to the business.

    I finally appreciate the new C# way that lets you define multiple out params for simple scalar parameters.

    In that sense, the Progress ABL was ahead of its time.  Why not using it?

    Procedures, Methods, UDF, all those are routines.  UDF and Methods have many advantages over procedures :

    -strong typing for a return value

    -signature check at compile time

    -completion in the editor

    -MUCH FASTER than a proc because no need to check existence of the routine and the signature at runtime (that was done at compile time)

    -more standard for new developers

    View online

     

    You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

    Flag this post as spam/abuse.

    Das Bild wurde vom Absender entfernt.
     

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • Mike, of course I've been there.  Sometime dealing with an object if fine, and sometimes it is not.  For sure adding a param to a procedure is a nightmare, but doing it to a Method or a properly prototyped UDF (not called with DYNAMIC-FUNCTION) is not always a nightmare.

    Anyway, one of my favourite type of parameter is the BUFFER PARAMETER with the same name as the target table or temp-table name... sadly many people neglect this historical low level type of object that is the record buffer...

    ...but that might start another flame ;)

  • I agree, but if I find it a bit overkill to make a new program (class) for doing this small task, I find it easier to use a function. I there is other ways of doing oo, please enlight me 😊
     
    //Geir Otto