15 replies to this topic

[Richard Bassett]

I've been trying to analyze some stuff with callable functions (dependencies, incorrect argument lists/types etc.).

The first character of the key to the glfintfs.pro file appears just to be an 'F' (which I guess stands for function or something). My question is whether you ever see other values for this character and, if so, in what circumstances.

I seem to recall this changed from V3 to V4 but have no idea why. I'm just wondering whether there's some other 'kind' of call that I'm not aware of.

TVM for any advice. (I'm working with V4.6 but I'm happy to be informed of stuff relevant to later versions.)


Incidentally, what I had presumed was the difference between 'B' and 'E' type parameters to global functions turns out to have been pretty inaccurate on closer inspection.. ISTM the only real difference is that an 'E' type entry defines the parameter variable whereas a 'B' type entry does not (and nor do 'I' or 'O').

It would be interesting to know other people's view on that as I wonder if it is not widely understood (the documentation certainly falls very short of explaining what's really going on).

FWIW, I'm only looking at reports and updates so the only invocation mechanism is GLOBAL_LSCALL().

[Cleve Haynes]

The first character of the key to the glfintfs.pro file appears just to be an 'F' (which I guess stands for function or something). My question is whether you ever see other values for this character and, if so, in what circumstances.

Hi

There is also "G" when calling a global function from a global logic. The function name is set to the global logic name in this case.

Cleve

[Richard Bassett]

Doh. Thanks Cleve, saves me figuring it out
Guess there aren't any in the system I'm looking at.

Another weird (to me) thing that maybe I forgot or just never got tripped by before.. the called global function name isn't in the key to glfintfs.pro..

Is it me, or is that just bizarre?

ISTM it forces you to invent a distinct, artificial 'interface ID' for every function you call - whereas otherwise we'd never need to worry about these IDs except in the case where we wanted to call the same global function with different actual arguments.

OK, the way it is you can use the same 'argument list' for different global function but how useful is that?! - far more likely to be a cause of coding errors IMHO.

[Brian Manners]

I might be the only one here who didn't know what TVM and ISTM meant (I sussed FWIW - aint I clever), but it just in case for others

TVM Thanks Very Much
ISTM It Seems To Me

Or possibly Richard meant one of these, that an acronymn finder website suggested:

TVM Target Via Missile
TVM Taiwan Video and Monitor Corporation
TVM Threat and Vulnerability Management
TVM Ticket Vending Machine
TVM Track Via Missile
TVM Traffic Volume Measurements

ISTM International Society for Testing Materials
ISTM International Society of Travel Medicine
ISTM Irish Society of Travel Medicine

Edited by Brian Manners, 21 April 2005 - 02:42 AM.

[Joseph Bove]

Richard,

Another weird (to me) thing that maybe I forgot or just never got tripped by before.. the called global function name isn't in the key to glfintfs.pro..

Is it me, or is that just bizarre?

I've never fully appreciated using the interfaces outside of fields...

I would much rather code and read someone else's code as:

GLOBAL_LSCALL(FUNCTION, PARAMETER 1, PARAMETER 2, etc).

I realize that this could be done by creating a global logic to call a global function, but that's somewhat tedious....

Joseph

[Richard Bassett]

Hi Joseph,

I would much rather code and read someone else's code as:
GLOBAL_LSCALL(FUNCTION, PARAMETER 1, PARAMETER 2, etc).
I realize that this could be done by creating a global logic to call a global function, but that's somewhat tedious....

Yeah, GLOBAL_LSCALL is brain-dead isn't it, I almost included a rant about it on the end of my OP <_<

I entirely agree that it would have been far better if calling functions from logic has simply followed the pre-existing example of LINK() - which is after all to call C functions. Also, like LINK, I can't see why the function to call shouldn't be an alpha expression and not just a literal (ie. could vary the function called at runtime).

I've never had to use global functions much, but I'm rapidly coming to the conclusion that, ideally, every global function should be wrapped in global logic and called that way. The advantages I see are:

As you say, you see the actual argument lists directly in logic.
You only have to setup and maintain one, central "interface" spec in the GL.
You get gen-time checking of argument types (doesn't happen with GLOBAL_LSCALL??)
It's easy to 'interpose' 'systemwide 'validation and debugging stuff in the GL.

You could actually have more than one GL wrapping the same global function where you want the convenience of a 'basic' API and a 'full' API - ie. when some arguments often have the same 'default' values. Of course this is also good for backward compatibility when you 'extend' the parameter list of a global function but want existing calls to continue working without change.

However - if anyone knows of bugs or gotchas relating to calling global functions from global logic I'd really like to know

TIA, Richard


PS. Brian, IMHO = In My Humble Opinion, OP = Original Post[er], TIA = Thanks in Advance, more if/when I think of them
You're clearly spending too much time in the real world instead of cyberspace

[Mike Nicholson]

Have done that a few times with global functions and while in some ways it does make it fairly simple you still have to maintain all the interfaces to the global logics to add a parameter (unless you want to start EXTERNing variables which I don't like doing).

Also a potential issue is that every global logic counts as a logic point towards your 255 max. Not a problem with smaller functions but I've worked on functions that would have gone kablooey a while back if every GF was called from a GL.

Cheers

Mike

[Cleve Haynes]

However - if anyone knows of bugs or gotchas relating to calling global functions from global logic I'd really like to know

If you use Pro-Aide, there is a serious gotcha (bug) with this.

Basically, you cannot edit a global logic that calls a global function using Pro-Aide because it always sets the interface type to "F" in GLINTFS instead of "G". Your function won't gen.

You need to use @GLOGIC when editing in order for the correct interface type to be set.

Cleve

[Richard Bassett]

Thanks Mike,

Have done that a few times with global functions and while in some ways it does make it fairly simple you still have to maintain all the interfaces to the global logics to add a parameter (unless you want to start EXTERNing variables which I don't like doing).

Well, not quite, or at least not necessarily immediately. As I suggested, you could create a new GL wrapper 'version' exposing the extended 'interface' and simply modify the original wrapper to 'default' the added parameters where this is feasible. Then you can use the new wrapper for the new functionality and bring the remainder of the source base 'up to date' at your leisure (stop laughing at the back). Of course this potentially advantageous approach is frequently scuppered by the 255-logic problem.

In cases where existing callers have to provide the new parameter(s), obviously you have to modify all the 'interfaces' anyway whether these are global logic calls or direct GLOBAL_LSCALL. And then the advantage of errors in global logic calls being detected at gen-time is considerable ISTM.

I agree nobody in their right mind would EXTERN a variable if it can be avoided
I have, sometimes (perhaps reprehensibly), used the technique of defining variables in "pseudo" filedefs that are never actually accessed - because the scope of "file" variables of course extends to global logic without using EXTERN.

Also a potential issue is that every global logic counts as a logic point towards your 255 max.

In reality, that is indeed a huge problem and is the main reason I said "ideally" {sigh}
For me , this historical (make that hysterical) limit is one of the single biggest problems with ProIV because it stymies many, many useful improvements to application code and structure.


Thanks again Cleve,

As it happens, I've never had to work on a system using Pro-Aide though.

[Richard Bassett]

Thanks Paul,

I'll try and test that so I know if my preference for 'GL wrappers' is OK for all cases.
I'll let you know if it seems to work for me so we can figure out why.

[Richard Bassett]

Hello again Guest_Paul,

One bug that I came across a while ago, was that the use of arrays in the interface of a global function being called from a global logic did not work. The global is just never called!  This was reported to Pro-iv and I've had nothing back since, so I presume it is still outstanding.

Yeah, well, you're not wrong are you..
Basically this stuff just doesn't work properly (at least in V4.6).

I guess it's not surprising there were no GLOBAL_LSCALLs from global logic in the system I was looking at and that not many people use the technique!

I spent (wasted) a couple of hours testing this because I hoped to be able to recommend it. I succeeded in confusing myself a few times but I think the problem is approximately as follows:

When one tries to call global functions from global logic, there are several cases in which ProIV fails to run the global function even though the interface is correctly specified. ProIV returns a -662 error, which I assume is a (spurious) "argument type mismatch".

The only array variables that seem to work as arguments in the "interface" are file variables. A scratch array that appears in a PARMS, EXTERN or DEFINE statement seems to cause a spurious error.

Non-array scratch variables that appear in a PARMS or DEFINE statement do appear to work. However even non-array scratch variable that appear in an EXTERN statement seem to cause a spurious error..

Nice.

[Donald Miller]

Richard

Strangely enough using the same argument list for different global functions is quite useful. In my weird view of trying to keep things as simple as possible (especially for Brian - KISS) this can actually help.

But then I like IF X=Y ELSE .....

[Rob Atherton]

Strangely enough using the same argument list for different global functions is quite useful. In my weird view of trying to keep things as simple as possible (especially for Brian - KISS)  this can actually help.

Hi Donald,

The problem when using the same Interface ID for different globals is that someone may change the parameters for function A (say remove or change one). It is quite probable that they won't check to see if the Interface ID is used for different functions which could cause problems in function B which is also using the amended Interface ID.

You'd probably get away with adding new parameters but it's still a bit dodgy.

[Chris Pepper]

This is also the reason it can seem like a good idea to use the same logic id more than once in a Function. At the time you write it it seems logical and efficient. It's only when the system is being maintained later (maybe years later!) that a change is needed that is not the same in both places. Or the second programmer doesn't spot that the code is also used elsewhere.