Procedure's default argument bypass Request

[charvista]

As spoken in the topic http://www.purebasic.fr/english/viewtop ... 13&t=49442, I am doing my request for a procedure's default argument bypass.
Like in some other languages, arguments that can be jumped are left empty or may have just an asterisk for more clarity. By jumping these arguments, the called procedure will still use their default value.

Code: Select all

Procedure Ax(a,b,c=1,d=7,e=3,f=9,g=1)
    Debug a
    Debug b
    Debug c
    Debug d
    Debug e
    Debug f
    Debug g
EndProcedure

Ax(100,200,*,*,*,*,4)

The variables a and b are mandatory, but the variables c to g have a default value. If I want to call Ax() and enter the value g=4 instead of the default g=1, asterisks might be used to jump to g.
Do you accept this for a future release?

[Shield]

+1 since I'm not expecting to get function overloading any time soon,
I think this is a good substitution and probably easier to implement.

[c4s]

It's an interesting approach which doesn't break existing code... I vote a +1

[Derren]

I use a work around with #PB_Ignore.

Code: Select all

Procedure Function(a, b, c=7, d=4, e=9)
	If c=#PB_Ignore: c = 7 : EndIf 
	If d=#PB_Ignore: d = 4 : EndIf 
	If e=#PB_Ignore: e = 9 : EndIf 
	
	Debug a
	Debug b
	Debug c
	Debug d
	Debug e
EndProcedure 

Function(1, 1, #PB_Ignore, 19)

That's the way PB handles this currently, although not nocessarily with optional parameters. c.f. ResizeWindow() which handles resizing a window and moving a window at the same time.

[Tenaja]

I will +1 this. While I don't know when I will need it, it will be simple to implement, and I can certainly see the value in it.

[Shield]

@Derren:
Yes, but that means that the value of #PB_Ignore cannot be used for anything else.
It might work in some cases, but charvista's suggestion works in all of them, especially with string parameters.

[ozzie]

+1. Had this feature in VB6 and used it extensively. Very useful for calling procedures with many parameters with defaults, when I just need to set a different value for a parameter near the end of the list.

[uwekel]

+1

[Danilo]

Code: Select all

Procedure Ax(a,b,c=1,d=7,e=3,f=9,g=1)
    Debug a
    Debug b
    Debug c
    Debug d
    Debug e
    Debug f
    Debug g
EndProcedure

Ax(100,200,*,*,*,*,4)

Empty expressions would be the same:

Code: Select all

Ax(100,200, , , , ,4)
Ax(100,200,,,,,4)

I prefer empty expressions over using ,*,*,*,* as it is faster to type - especially with German keyboard


Another (additional) option would be to implement named arguments:

Code: Select all

Ax(100,200,g=4)  ; same as Ax(100,200,1,7,3,9,4)

[charvista]

Ax(100,200, , , , ,4)
Ax(100,200,,,,,4)

Looks okay to me, I appreciate this alternative, however if you have 40 commas, you will have to count very carefully, and probably more than once, as counting errors may occur. If you wink once, you may need to count again. It may be easier to type, but not to read afterwards.

Ax(100,200,g=4) ; same as Ax(100,200,1,7,3,9,4)

Oh no, I am very sorry, this is too dangerous. Too misleading, because we could think it is the 3rd parameter, while in reality it is the 7th!
If I am passing you my programs, and you read this:

Code: Select all

Bx(4,"AB",Name.s="PB",V=8)

you can not know which parameter number it is! Name.s could logically be the 3rd, but it could be the 8th as well, and V could be the 14th or 17th!

[luis]

Looks okay to me, I appreciate this alternative, however if you have 40 commas, you will have to count very carefully, and probably more than once, as counting errors may occur. If you wink once, you may need to count again. It may be easier to type, but not to read afterwards.

I totally agree.

Oh no, I am very sorry, this is too dangerous. Too misleading, because we could think it is the 3rd parameter, while in reality it is the 7th!

You don't have reason to think it is a parameter to a particular position. Not the 3dh, not the 7th.
Why you should care ? You identify it by its mnemonic.
The only thing the compiler must check is you are not allowed to specify the same param twice, by position and then by mnemonic.

If I am passing you my programs, and you read this:

Code: Select all

Bx(4,"AB",Name.s="PB",V=8)

you can not know which parameter number it is! Name.s could logically be the 3rd, but it could be the 8th as well, and V could be the 14th or 17th!

And why I should care ?

I don't see a problem with that as long the params using mnemonics are specifiable only at the end of the positional ones to avoid confusion.

[Shield]

Ax(100,200,g=4) ; same as Ax(100,200,1,7,3,9,4)

Oh no, I am very sorry, this is too dangerous. Too misleading, because we could think it is the 3rd parameter, while in reality it is the 7th!

It doesn't matter which number it is because you explicitly specified its name.
Not dangerous at all and implemented properly in many other languages.

[skywalk]

Yeah, I would like blanks instead of '*' or #PB_Ignore.
The point is to reduce typing.
If you have function calls with 40 parameters then time to break out a structure instead
Named parameters is interesting but seems not Basic.
But, now that we have Bool(), there wouldn't be a conflict with myProc(1,2,param1=5).

[charvista]

Hmm, it is true that we have the mini-help line when we are coding, and the defaults are visible.
Okay, for the compiler it may not be a danger at all, but we are humans and we don't read like a machine. But after thinking a bit, maybe Danilo's idea might be good. However, I still prefer the respective positioning.
And for thinking further, if there are two values that we want to override their default, do we have to respect the order, or not? Imagine you want the e=12, and g=4, can the compiler accept both arrangements?:

Code: Select all

Ax(100,200,g=4,e=12)

or

Code: Select all

Ax(100,200,e=12,g=4)

[Shield]

Yes, of course. Because you named them.