how to or could I ?

Posted by goo on 14-Feb-2018 11:24

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 :-)

Posted by gus bjorklund on 14-Feb-2018 13:40

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

Posted by gus bjorklund on 14-Feb-2018 13:40

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.

Posted by goo on 14-Feb-2018 14:22

Thanks Gus, Nice to know :-)

Posted by marian.edu on 15-Feb-2018 00:18

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

Posted by slacroixak on 15-Feb-2018 02:31

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

Posted by marian.edu on 15-Feb-2018 02:42

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

Posted by Patrick Tingen on 15-Feb-2018 03:47

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.

Posted by Mike Fechner on 15-Feb-2018 03:56

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.
 

Posted by slacroixak on 15-Feb-2018 05:57

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

Posted by marian.edu on 15-Feb-2018 06:52

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

Posted by bronco on 15-Feb-2018 08:21

[quote user="marian.edu"]guess a trip to the dark side (javascript) may break any strongly type developer :D[/quote]

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

Posted by marian.edu on 15-Feb-2018 08:32

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 ;)

 


Posted by bronco on 15-Feb-2018 10:07

Until they blew up the Death Star because of some very hard to find omission [8-|] 

This is getting nowhere :-)

Posted by Mike Fechner on 15-Feb-2018 11:28

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.
 

Posted by slacroixak on 15-Feb-2018 11:58

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 ;)

Posted by goo on 15-Feb-2018 12:16

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
 

Posted by Jean-Christophe Cardot on 16-Feb-2018 10:09

I second Sebastien on the buffer parameter. Having to maintain a legacy coded in ABL, I'm using it quite often, then I can add as many parameters as I want.

Also for simpler cases of procedural input params I tend to add a last parameter that might contain a list of param=value couples, which do the trick more often than not. I could go json also ;)

I'm missing named, optional parameters in fact. PSC, someone?

This thread is closed