Skip to main content

Hi UnifAce

I want to include a call to an ENTRY every time an OPERATION is called, just for debug purpose.
OPERATION XYZ
params
  string v_PARA:INOUT
endparams
  call SP_OPR_GO_IN("XYZ",v_PARA)
And 
SP_OPR_GO_IN
params
  string v_PARA:IN
endparams
IF(!$$DBG) RETURN(0) ; Not in debug, do nothing
...

If v_PARA is filled by lot of data, this could be time consuming.
So

OPERATION XYZ
params
  string v_PARA:INOUT
endparams
 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

Hi UnifAce

I want to include a call to an ENTRY every time an OPERATION is called, just for debug purpose.
OPERATION XYZ
params
  string v_PARA:INOUT
endparams
  call SP_OPR_GO_IN("XYZ",v_PARA)
And 
SP_OPR_GO_IN
params
  string v_PARA:IN
endparams
IF(!$$DBG) RETURN(0) ; Not in debug, do nothing
...

If v_PARA is filled by lot of data, this could be time consuming.
So

OPERATION XYZ
params
  string v_PARA:INOUT
endparams
 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

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. 

Hi UnifAce

I want to include a call to an ENTRY every time an OPERATION is called, just for debug purpose.
OPERATION XYZ
params
  string v_PARA:INOUT
endparams
  call SP_OPR_GO_IN("XYZ",v_PARA)
And 
SP_OPR_GO_IN
params
  string v_PARA:IN
endparams
IF(!$$DBG) RETURN(0) ; Not in debug, do nothing
...

If v_PARA is filled by lot of data, this could be time consuming.
So

OPERATION XYZ
params
  string v_PARA:INOUT
endparams
 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

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

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. 

Hi Iain

Convert from/to struct cost also time 🙂
BTW:  Most of time v_PARA is an empty string, so a convert worse the problem ...

Ingo


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.

Ingo



Hi UnifAce

I want to include a call to an ENTRY every time an OPERATION is called, just for debug purpose.
OPERATION XYZ
params
  string v_PARA:INOUT
endparams
  call SP_OPR_GO_IN("XYZ",v_PARA)
And 
SP_OPR_GO_IN
params
  string v_PARA:IN
endparams
IF(!$$DBG) RETURN(0) ; Not in debug, do nothing
...

If v_PARA is filled by lot of data, this could be time consuming.
So

OPERATION XYZ
params
  string v_PARA:INOUT
endparams
 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

Hi all,

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?

Gianni

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

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

Hi all,

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?

Gianni

Hi Gianni

This would be make sense, for sure.
But the logic of UnifAce is to copy parameters
IN:         Copy on going in
OUT:     Copy on going out
INOUT:  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 easy
b) to insure, that an IN could not modify the calling variable

BUT
a) using CALL is always on the same process instance of UnifAce
b) With structs, we do have such possibilities


@UnifAce: with 9.8, we have a call by reference for string, or? 🙂

Ingo

Hi all,

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?

Gianni

Hi Ingo,

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 reference
and 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.

Gianni

Terms & ConditionsAccessibility statement