PxPlus User Forum
Main Board => Discussions => Language => Topic started by: RobL on September 07, 2018, 02:06:12 PM
-
Hello all!
I'm experimenting with using a combination of a local function, XEQ() and a CALL routine, as a substitute for using a global function. I've got it working and I'm happy with the results, except for one issue. I can't figure out how to LOCALize the variable that returns the value from the CALL routine.
Here's an example:
! test
begin
extension$=".exe"
print "extension$ - before: ",extension$
file_ext$=fnget_extension$("myfile.jpg")
print "file_ext$: ",file_ext$
print "extension$ - after: ",extension$
end
!
def fnget_extension$(local filename$)=xeq("functions;get_extension",extension$,filename$,extension$) ! get the file extension from the specified filename
! functions
GET_EXTENSION:! get file extension from the specified filename
enter (filename$),extension$
extension$=""
p=pos("."=filename$,-1)
if p then extension$=filename$(p+1)
exit
Here's the output :
->run
extension$ - before: .exe
file_ext$: jpg
extension$ - after: jpg
->
I tried adding LOCAL to parameters in the XEQ() statement, but that results in an error 20.
Is there any way to prevent extension$ from being modified?
Regards,
Rob Leighton
Riverwood Enterprises Inc.
-
There is no way to 'localize' XEQ parameters however for your example I have a couple of suggestions, either of which should yield what your want:
- Make your function into a multi-line function and use LOCAL there to localize the variables.
- Replace your whole function with def fnget_extension$(local filename$)=arg(sub(filename$,".",sep,-1),2)
Basically the above replaces the last "." with a field separator then asks for the second argument. If no dot was present there will be no second arg thus the logic will return "".
-
Another option is to use a unique variable to avoid conflict. Something like this:
def fnget_extension$(local filename$)=xeq("functions;get_extension",fnget_extension_ret_val$,filename$,fnget_extension_ret_val$)
Even better is to wrap these functions into a global object so you do not have a maintain a bunch of scattered local functions and their associated iolists throughout your application.
-
Chris:
Using a unique variable name is the approach I used in the past that I'm trying to avoid. Normally, I'd just use global functions, but in this instance I'm trying to create a standalone module that will have zero impact on the existing codebase.
There aren't alot of these functions, but they are used throughout this module. In some timing tests I did, using XEQ / CALL performed as quickly as global functions, and a nice side benefit is you can single-step through the code when debugging. I even thought about using objects, but that seems like overkill...
Mike:
Thanks! #1 is the obvious answer (now that you've pointed it out) and #2 will come in handy for something else!
Regards,
Rob
-
Rob, I was doing a review of this issue and had a thought.
Why are you passing two arguments to the called program?
Why not just pass filename$ (which is LOCAL) and have the called program simply change that variable to the extension and return it? This avoids needing a extra variable and having to figure out what would be safe to use.
-
Hi Mike,
You are correct! It can be eliminated. There was a reason at the time, but not anymore. Thanks for the second look!
Regards,
Rob