There is also this feature request for named parameters:
https://tracker.xojo.com/xojoinc/xojo/-/issues/56286
Not really related. I did not like most of the conversation on this topic trying “to emulate a bit with trade offs” the feature. And this FR is just something related to autocomplete.
If a language supports, there are 2 kinds of parameter passing, positional and named.
Let’s take for example: Function foo(p1 As Integer, p2 As Integer, p3 As Integer)
Xojo supports positional. So for p1 = 11 and p2 = 22 and p3 = 33 a call is:
foo( 11, 22, 33 )
Now let’s assume that 11, 22, 33 are the parameters passed 95% of the time for foo(), we could make our life easier using defaults:
Function foo(p1 As Integer = 11, p2 As Integer = 22, p3 As Integer = 33)
So now, a pure foo() call equals to a foo( 11, 22, 33 ), same results.
When we have a special case with a p1 = 99 we just write foo(99) that’s equal to a foo( 99, 22, 33 )
But what happens when we want to change just p3? In Xojo you can’t. You’ll need to write the full sentence as foo( 11, 22, 99 )
If Xojo had named parameters we could write foo( p3:=99 ) and the compiler would render it as foo( 11, 22, 99 ) internally.
So is this something lazy that can be substituted by a full smart autocomplete? No.
Let’s assume you used an autocomplete and ended with foo( 11, 22, 99 ) in several places and your colleague using another language wrote the same method using named parameters as foo( p3:=99 ).
In a sunny day, someone in the government decided to change a law, and demanded that p2, usually 22, now must be 23…
Your colleague then edited his foo() parameter list
from Function foo(p1 As Integer = 11, p2 As Integer = 22, p3 As Integer = 33)
to Function foo(p1 As Integer = 11, p2 As Integer = 23, p3 As Integer = 33)
And… done.
But you, you need to do the same, but also revisit all your code, all the places where you autocompleted foo() calls, and the p2 has a fix 22 value there as foo(11, 22, 99) and you will need to rewrite each one as foo(11, 23, 99) until something changes again. This approach spreads sensible points in our code, if you forget one change in 30 places, a bug is introduced. Your colleague concentrated the sensible part in one place, in a elegant and performant manner, not with “more code” IN the method.
1 Like
How about foo ( , , 99) with the missing params being given their default values ?
That’s one positional approach that could also be explored, but leads to 2 problems:
Unreadable weird code if you don’t have a named option, as:
bar( , , , , , , , , , , , , , , , , , , 7, , , , , , “ok”, , 0 )
And a bug spreader if you change the parameter list adding or removing parameters.
1 Like
Yes. I prefer to stick with what we have.
So you don’t need to discuss the matter, you are already satisfied with the basics Xojo already have.
Just because I am content with what exists, does not prevent me from suggesting alternatives.
1 Like
I guess I’m not understanding. What alternatives?
The one I suggested about three posts ago, to which you replied pointing out a couple of possible problems.
Oh, I see. You are correct. A question, that I previously not classified as an alternative. Thank you for the previous participation.