Uniface on GitHub
Product (releases and patches)
Fixes and Updates
I want to include a call to an ENTRY every time an OPERATION is called, just for debug purpose.OPERATION XYZparams string v_PARA:INOUTendparams call SP_OPR_GO_IN("XYZ",v_PARA)
And SP_OPR_GO_INparams string v_PARA:INendparamsIF(!$$DBG) RETURN(0) ; Not in debug, do nothing...
If v_PARA is filled by lot of data, this could be time consuming.So
OPERATION XYZparams string v_PARA:INOUTendparams IF($$DBG) call SP_OPR_GO_IN("XYZ",v_PARA)
should be a better solution.
Now I have to check for $$DBG in every place a call the global proc.Not the problem, if the condition is this easy.But what if, the condition is not this easy but a little bit tricky?
Is there any way to pass a parameter by reference (pointer) even if it is "only" a string?[EDIT: a reference to a const expression]In every moderen language this is possible (may be behind the curtain)And UnifAce is a modern language, or ... Ingo
Uniface syntax for parameters is already providing clauses IN | OUT | INOUT; does it makes sense all IN parameters should be passed by value and all OUT and INOUT parameters should be passed by reference?
This would be make sense, for sure.But the logic of UnifAce is to copy parameters IN: Copy on going inOUT: Copy on going outINOUT: Copy on going in and then copy on going out
A few years ago, I did modify all INs to INOUT to get performance.After this, the time on call a ENTRY was doubled
I understand UnifAce, a) if you call another component on another session (application server&co), marshiling of pointer is not easyb) to insure, that an IN could not modify the calling variable
BUTa) using CALL is always on the same process instance of UnifAceb) With structs, we do have such possibilities
@UnifAce: with 9.8, we have a call by reference for string, or?
IMHO Uniface is a 4GL expanded to be a 3.5GL.
I would personally prefer to stay on higher level, sticking to common rule:- IN: by value- OUT: by reference- INOUT: by referenceand when partitioning and other interprocess communications take place, ALL_TYPES by value, because introduction of ByRef and ByValue is a pure 3GL definition, not in line with Proc Script.
I did NOT appreciated the addition of ByRef and ByValue for structs.
1) check the possibility of evaluating the "a little bit tricky" in application startup and store/use result in $$DBG
2) an included proc can work with the local v_para, no need to call an external proc
SP_OPR_GO_IN was only an example and/or did not include alll parameters.And some times, the behavior depends from a parameter.Writing this as an include was an idea too.But:
a) The syntax to call such "template" is not intuitive. UnifAce miss a define of macros like C/C++
b) If there is a need to change the behavior, one have to recompile all components.
Unfortunately coding for speed is always hard work (and some compromises):
you may have to type inline assembler code or concentrate all implementation into a single entry trading repeated codelines (violating DRY) against reduced execution time etc.
As one can come pretty near to a "c macro functionality" experience with Uniface possibilities
We are left with the final cost/benefit question:
"recompiling all components" against an improved execution speed
Well, you could put the para in a struct, and then pass the struct as a para. That (If I understand correctly) would only pass the pointer to the struct.
But there's then the performance issue (if any) of getting the data into/out of the struct.
Convert from/to struct cost also time BTW: Most of time v_PARA is an empty string, so a convert worse the problem ...
© 2019 Uniface Privacy & Cookies | Privacy Statement | Legal