Procedures - optional parameter more flexible

[GPI]

for example:

Code: Select all

declare.s Example(id=#pb_any,x,y,w,h,Invisible=#false,readonly=#false)

Example (,0,0,100,20,,#true); should be expaned to Example(#pb_any,0,0,100,20,#false,#true)

It is also usefull for many build-in Bibliotheks.

So for example

TextGadget(#pb_any,0,0,100,20,"Hello")
could be reduced to

TextGadget(,0,0,100,20,"Hello")

[c4s]

Doesn't look very nice but good idea. +1

[Little John]

So for example

TextGadget(#pb_any,0,0,100,20,"Hello")
could be reduced to

TextGadget(,0,0,100,20,"Hello")

No, please!
That is worse readable, at least for me.

[STARGÅTE]

I think this is hard to read.
Many people already have problems with normal default parameters, like this standard fail:

Code: Select all

PokeS(*Buffer, "Hello World", #PB_UTF8)

instead of the correct syntax

Code: Select all

PokeS(*Buffer, "Hello World", #PB_Default, #PB_UTF8)

because the third parameter is always the length, und the fourth is the mode!

If some codes in the Forum like your new syntax:

Code: Select all

PokeS(*Buffer, "Hello World",, #PB_UTF8)

many readers fail to see the second comma and cause errors!

But, yes, it is an optional feature, so from me no like or dislike

[Little John]

But, yes, it is an optional feature

Not exactly.
When writing code, it would be optional: One could use this style or normal stlye.
But when someone would post code in this style here on the forum, we can only read it as it has been posted.
When reading code, there are no options.
Introducing an option that allows to write less readable code just doesn't make any sense.

[skywalk]

It is also usefull for many build-in Bibliotheks.

I don't understand this statement. Do you mean existing libraries?
In general, I would use this feature. There are frustrating cases where I only want to change the last optional parameter of a procedure call, but I have to retype 4 or 5 defaults before I get to the change I need to make.

Code: Select all

Procedure.i DoIt(a,b,c,op1=#SomeConst1,op2=#SomeConst2,op3=#SomeConst3)
DoIt(a,b,c,,,4) ;<-- Much less typing and no way I miss that empty commas are defaults.

[IdeasVacuum]

Introducing an option that allows to write less readable code just doesn't make any sense.

+1

[Danilo]

It is used in some other BASIC's.

- Optional Parameters (Visual Basic)

Calling Procedures with Optional Parameters

When you call a procedure with an optional parameter, you can choose whether to supply the argument.
If you do not, the procedure uses the default value declared for that parameter.

When you omit one or more optional arguments in the argument list, you use successive commas to mark their positions.
The following example call supplies the first and fourth arguments but not the second or third:

Code: Select all

sub name(argument 1, , , argument 4)

The following example makes several calls to the MsgBox function. MsgBox has one required parameter and two optional parameters.
The first call to MsgBox supplies all three arguments in the order that MsgBox defines them.
The second call supplies only the required argument.
The third and fourth calls supply the first and third arguments.
The third call does this by position, and the fourth call does it by name.

Code: Select all

MsgBox("Important message", MsgBoxStyle.Critical, "MsgBox Example")
MsgBox("Just display this message.")
MsgBox("Test message", , "Title bar text")
MsgBox(Title:="Title bar text", Prompt:="Test message")

FreeBasic:

Code: Select all

DECLARE SUB Test(A AS DOUBLE = 12.345, BYVAL B AS BYTE = 255)

Test
Test , 128
Test ,
Test 44,
Test 44
Test ( )

' GET #Filenumber, [Position], Variable

GET #1, , x

BlitzMax:

Code: Select all

Function DoIt(a=1, b=2, c=3, d=4)
    Print( String(a)+":"+String(b)+":"+String(c)+":"+String(d) )
End Function

DoIt(,,,5) ' output: 1:2:3:5

MonkeyX:

Code: Select all

Function DoIt(a=1, b=2, c=3, d=4)
    Print( String(a)+":"+String(b)+":"+String(c)+":"+String(d) )
End Function

Function Main()
    DoIt(,,,5) ' output: 1:2:3:5
End

[GPI]

It is also usefull for many build-in Bibliotheks.

I don't understand this statement. Do you mean existing libraries?

sorry, wrong word - i mean the libraries. In many cases i use "#pb_any" as first parameter. It would be much faster to write simple a "," than "#pb_any,"

[Danilo]

In many cases i use "#pb_any" as first parameter. It would be much faster to write simple a "," than "#pb_any,"

Currently, every parameter following an optional parameter must be optional, too. Optional parameters always stay at the end of the parameter list,
with the current implementation.
With the feature request "empty argument uses default argument" implemented, you would still need to type '#PB_Any' for the first argument.
So the important part is, you like to have default arguments at every position. It is little bit different from optional arguments.

[Demivec]

Another option that has merits is 'Named Parameters'. It is another way of handling optional arguments. You simply name which of the optional arguments you are supplying.

It won't necessarily shorten the amount of typing. It can't handle cases where groups of optional parameters are required to be specified if any of them are specified (though I can't think of much that would fit this case).

It would keep compatibility with older code because the optional parameters can still be specified by their order and wouldn't change the way the procedure declarations are made. It would increase the complexity of parsing the code for compiling because the optional parameters would have their names matched. It would give some freedom in determining the order of the optional parameters (which can be a source of frustration) for both the users and the creator of the language.

Here are a lot of examples:

Code: Select all

AddStaticGeometryEntity(0, 10, 5, -2, 5, ScaleZ: 2.2, RotateY: -1.6)
ApplyEntityForce(0, 10, 5, 2, PositionX: -1.0)
AttachEntityObject(0, "leg", 3, Yaw: 19.3) 
BindEvent(#PB_Event_Gadget, @GadgetHandler(), EventType:#PB_EventType_LeftClick) 
CompareMemoryString(*String1, *String2 , Flags:#PB_UTF8)
CreateCylinder(#Mesh, 3.2, 5, VerticalShift:1)
CreateImage(#Image, 500, 400, BackColor:RGB($10, $F0, $40))
CreateText3D(#Text3D, "Testing", Color:RGB(0, 0, $FF))
Date(Year:2014, Month:m)
DisplayTransparentSprite(#Sprite, 10, 12, Color:RGB($FF, $FF, $FF))
DrawText(x, y, Text$, BackColor:RGB(255, 128, 128))
FillMemory(*Memory, Size, Type:#PB_Word)
FindString(String$, "Fred", Mode:#PB_String_NoCase)
NodeLookAt(#Node, 2, -3, 15.2, DirectionZ: 0.35)
OpenScreen(1280, 800, 32, "Game", RefreshRate:60)
OpenWindowedScreen(WindowID(0), 0, 0, 500, 300, #True, FlipMode:#PB_Screen_NoSynchronization) ;AutoStretch specified positionally
PokeS(*Buffer, "Hello World", Flags:#PB_UTF8)
PostEvent(#PB_Event_Gadget, Object:3, Data:*data)
RemoveString(String$, "bug", NbOccurrences:3)
SaveImage(#Image, Filename$, Depth:8)
TransformSprite(#Sprite, x1, y1, x2, y2, x3, y3, x4, y4, z1:15, z4:15) ;this is a unusual example

It would be useful anywhere the optional parameters are numerous (just look at the 3D and multimedia libraries).

[Danilo]

See also: Procedure's default argument bypass Request

[Demivec]

See also: Procedure's default argument bypass Request

I had forgotten about that thread. There was one important thing mentioned there: because we now have Bool() we can use '=' with a possible named argument implementation.

This would make it possible to write one of my earlier exames like this:

Code: Select all

PostEvent(#PB_Event_Gadget, Object = 3, Data = *data) 

I think named arguments are useful as documentation because they allow you to show which of the optional parameters are important to you and don't require you to include all the other optional ones simply to keep the ordering of the parameters and thus specify them with their default values.

I am not as worried about the length of the line, though short lines are preferred, because I can use line continuation if needed.

A more preferred solution would be overloaded procedure calls that can accept more than one list of parameters or parameter types. Since that isn't going to happen in the foreseeable future (or ever) I won't mention it further.

[Little John]

Thanks for mentioning named parameters here!
I like them, because they are self-documenting and also very flexible.
Using a workaround, we can use named parametrers in PB even now, see this trick.

[Danilo]

Using a workaround, we can use named parametrers in PB even now, see this trick.

You could do string parsing at run-time before. The feature request is a compile-time feature
and does not affect or degrade run-time performance.