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 :-)
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.
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).
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?
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.
|
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 :)
[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).
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 [8-|]
This is getting nowhere :-)
|
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 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?
