Optional subroutine parameters?

[johannhowitzer]

Is it possible to make one or more parameters at the end of a sub or function optional when calling, and then those would just have default values in the subroutine?  For example

call example(10, 20)

sub example(x, y, text$)
...
end sub

And then in the call, text$ is an empty string?

[SpriggsySpriggs]

Unfortunately, no.

[RhoSigma]

Code: QB64: [Select]

1. TYPE sub_example_params
2.     x AS INTEGER
3.     y AS INTEGER
4.     t AS STRING
5. END TYPE
6.  
7. DIM call_params AS sub_example_params
8.  
9. call_params.x = 10
10. call_params.y = 20
11. CALL example(call_params)
12. END
13.  
14. SUB example (params AS sub_example_params)
15. 'each param entry has whatever value was last written to it, hence not necessarily empty,
16. 'to make it happen, you should ivalidate all params at the end of the sub to make them defaults
17. 'for the next call
18. params.x = 5: params.y = 5
19. params.t = ""
20. 'this would be the defaults for the next call unless they're changed before the next call
21. END SUB
22.  

Backdraw, you need a lot of individual TYPEs for your individual SUBs/FUNCs...

[RhoSigma]

In alternative you could also use the TagString API, which I've developed for my GuiTools Framwork (see signature). You find the required tagsupport.bi/.bm files in the QB64GuiTools.7z archive in folder dev_framework\support. A description of the tag functions can be found in docs\GuiToolsFramework.pdf

It requires more writing, but comes very close to what you want:

Code: QB64: [Select]

1. '$INCLUDE: 'tagsupport.bi'
2.  
3. 'entirely default params (white "default text" at position 5, 5)
4. CALL example("")
5.  
6. 'text with y position
7. CALL example(NewTag$("YPOS", "10") + NewTag$("TEXT", "This is my given Text at line 10"))
8.  
9. 'the order of tags doesn't matter
10. CALL example(NewTag$("TEXT", "This is my given Text at line 15") + NewTag$("YPOS", "15"))
11.  
12. 'and with color
13. CALL example(NewTag$("TEXT", "This is my given green Text at line 20") + NewTag$("COLOR", "10") + NewTag$("YPOS", "20"))
14.  
15.  
16. SUB example (tags$)
17. x% = VAL(GetTagData$(tags$, "XPOS", "5")) 'default pos = 5, if not given
18. y% = VAL(GetTagData$(tags$, "YPOS", "5"))
19. c% = VAL(GetTagData$(tags$, "COLOR", "15")) 'default color = 15 (white)
20. txt$ = GetTagData$(tags$, "TEXT", "default text")
21. '-----
22. LOCATE y%, x%
23. COLOR c%
24. PRINT txt$
25. END SUB
26.  
27. '$INCLUDE: 'tagsupport.bm'
28.  

[SMcNeill]

Code: QB64: [Select]

1. TYPE sub_example_params
2.     x AS INTEGER
3.     y AS INTEGER
4.     t AS STRING
5. END TYPE
6.  
7. DIM call_params AS sub_example_params
8.  
9. call_params.x = 10
10. call_params.y = 20
11. CALL example(call_params)
12. END
13.  
14. SUB example (params AS sub_example_params)
15. 'each param entry has whatever value was last written to it, hence not necessarily empty,
16. 'to make it happen, you should ivalidate all params at the end of the sub to make them defaults
17. 'for the next call
18. params.x = 5: params.y = 5
19. params.t = ""
20. 'this would be the defaults for the next call unless they're changed before the next call
21. END SUB
22.  

Backdraw, you need a lot of individual TYPEs for your individual SUBs/FUNCs...

There's a second problem with this approach: retained values not clearing between calls, or else values becoming altered (as per your example) after each call.

Honestly, I'd rather see something more like the following in my code:


SUB foo ( x, y, text$, passed)
   IF passed = 0 THEN passed = 7 'all are valid without a limiter
   IF passed AND 1 THEN 'x was passed
       ... stuff
   END IF
   IF passed AND 2 THEN 'y was passed
      ....

   IF passed AND 4 THEN 'text$ was passed
     ...

END SUB


So now I can :

foo 12, 13, "Hello World", 0 'all params passed
foo 12, 0, "", 1 'only X passed
foo 0, 13, "", 2 'only Y passed

And so on...

[bplus]

Is it possible to make one or more parameters at the end of a sub or function optional when calling, and then those would just have default values in the subroutine?  For example

call example(10, 20)

sub example(x, y, text$)
...
end sub

And then in the call, text$ is an empty string?

Yes can be done but PITA, so most people would say simply "no".

Besides Rho's method, just use a string (usually a space or comma value delimiter) for the input parameter and parse the string out inside the sub, you still have to use some sort of delimiter in string for the parsing unless all values are same length and order is not important.

Another way is to pass a string array with any number values passed as strings, with an array you can preserve order of parameters.

Psuedo code:
sub example(parameters$()) ' this requires parameters$() setup before calling sub
dim lb, ub, x, y, text$
lb = lbound(parameters$)
ub = ubound(parameters$)

x = val(parameters$(lb))
if ub >=1 then y = val(parameters$(lb + 1))
if ub >=2 then text$ = parameters$(lb + 2))
end sub

BTW using Call to call a sub is not necessary. When don't use Call, don't use () around arguments, much cleaner looking.

[madscijr]

Is it possible to make one or more parameters at the end of a sub or function optional when calling, and then those would just have default values in the subroutine? 

It seems like the workarounds have drawbacks that complicate things.
What I do is just write the main function with all the parameters, then define additional versions of the function with a slightly different name and less parameters, which pass whatever default values to the main function. It isn't perfect but it's the simplest approach.

[bplus]

What I do is just write the main function with all the parameters, then define additional versions of the function with a slightly different name and less parameters, which pass whatever default values to the main function. It isn't perfect but it's the simplest approach.

Nice, right that is probably simplest. In old days, when space was so precious you wouldn't think of multiple versions of basically the same function probably be more inclined to add switches to multi-purpose code. But nowadays, space is cheap and coding time and effort the more costly commodity. I like this answer best so far.

[madscijr]

Nice, right that is probably simplest. In old days, when space was so precious you wouldn't think of multiple versions of basically the same function probably be more inclined to add switches to multi-purpose code. But nowadays, space is cheap and coding time and effort the more costly commodity. I like this answer best so far.

In the past 4 decades since I first learned BASIC, I have learned lots of techniques and features from other more advanced languages, and seen so many new developments, features and techniques come along. Mostly they're meant to save the programmer time and make life easier. A lot of these features are supposed to help make code "reusable" and enforce "proper" design, etc.

And after a while I started realizing that the more complicated the languages, features and techniques get, the less they're actually saving time, while making everything painfully complicated.

I think that's one reason I have stuck with BASIC (including VBA) - it's powerful enough to do what I need, but simple enough that I don't have to jump down too many rabbit holes...

[luke]

I feel obliged to shamelessly advertise: https://qb64forum.alephc.xyz/index.php?topic=2778.msg139656#msg139656