One of the things which I initially found a little odd, although very simple to grasp, was the way that Uniface allows you to create modules of code as an entry, not a function. This entry has any number of parameters (well, there probably is a limit) which can be defined as "in", "out", or "inout". The only thing that is returned from this entry is a numeric status, which you return and this sets $status accordingly. I think it's fairly common that developers use a status of "0" to indicate successful and positive for additional successful status, then a negative status for errors. Any other type of value could be returned in an "out" or "inout" parameter.
This is a very simple mechanism and it works nicely. However, sometimes it can lead to some rather verbose code, as you have to put the call to the entry on a separate line, you can't nest the call within an if or while statement as part of the condition, for example. Here's a simple entry which converts kilometres into miles...
entry kms_to_mls_entr
params
numeric kms : in
numeric mls : out
endparams
mls = kms*5/8
return 0
end
A bit of a side note; I thought you always had to specify a datatype when defining a parameter, and that this was always a local variable. I discovered recently that you can also use a component variable or a painted field name, in which case you don't specify the datatype. For example...
entry kms_to_mls_entr
params
numeric kms : in
$miles$ : out
endparams
$miles$ = kms*5/8
return 0
end
This is a very simple mechanism and it works nicely. However, sometimes it can lead to some rather verbose code, as you have to put the call to the entry on a separate line, you can't nest the call within an if or while statement as part of the condition, for example. Here's a simple entry which converts kilometres into miles...
entry kms_to_mls_entr
params
numeric kms : in
numeric mls : out
endparams
mls = kms*5/8
return 0
end
To convert two values using the entry and then add them, it takes 3 lines, like this...
call kms_to_mls_entr(kms1,mls1)
call kms_to_mls_entr(kms2,mls2)
total = mls1 + mls2
From version 9 onwards (sorry, I can't remember the minor version number) you have another option. It took me a while to find any information in the manuals, but it's there; they're called "User-Defined Functions". Here's an example...
entry kms_to_mls_func
returns numeric
params
numeric kms : in
endparams
return kms*5/8
end
Notice that there is a returns statement before the params, which determines what datatype should be returned. In this case it is numeric, but it doesn't need to be. In this case, to convert the two values using this function, it takes a single line...
total = kms_to_mls_func(kms1) + kms_to_mls_func(kms2)
This can make the code a bit neater. But of course I'm obsessed with performance, so my next step is the test these two methods over 2,000,000 iterations...
- entry = 00:17.74, 00:17.69, 00:17.60 (under 18 seconds)
- function = 00:13.64, 00:13.64, 0:13.67 (under 14 seconds)
So as you can see, the code is more concise and it performs better. It also relies on less variables defined, so it's a win-win all round really. You can even do this with a global procedure.
A bit of a side note; I thought you always had to specify a datatype when defining a parameter, and that this was always a local variable. I discovered recently that you can also use a component variable or a painted field name, in which case you don't specify the datatype. For example...
entry kms_to_mls_entr
params
numeric kms : in
$miles$ : out
endparams
$miles$ = kms*5/8
return 0
end
Summary: It is possible to create a "user-defined function", which is an entry that returns a specific datatype, allowing you to create more concise code, that also performs better.
