Hi all, hopefully I didn’t just miss this but I am wondering if Xojo has a way to specify parameter names in the call. C# does this. In C# say you have
public void DoSomething( int parm1, string parm2, double parm3 )
You can call this with the parm name: DoSomething( parm1:29, parm2:“Hello”, parm3:3.1415 )
This can be really handy if you have a method with a fair number of parameters. I’m wondering if Xojo has anything similar?
In general, keeping with OO principles I try hard not to have methods with lots of parameters. But at times you need them. For example I use MessageDialog to prompt the user. There are a lot of options to a MessageDialog so I’ve created my own method:
ShowWarningDialog(caption as string, message as string, explanation as string, actionButtonText as String)
While there are only four parms to this one, it would be super nice to be able to call it like:
ShowWarningDialog( caption:“Hello World”, message:“It’s gonna be a great day”, explanation:“Because I lived to see it”, actionButtonText:“Let’s go”)
It makes it really clear what is being assigned to what.
With regards to classes or subclassed objects, I think about the closest you can get is start with a Constructor with no parameters, then set the arguments as properties, then call a method to perform whatever logic you need (which would otherwise be in your Constructor). Something like:
Var d As New WarningDialog()
d.Caption = "Hello World"
d.Message = "It's gonna be a great day"
d.Explanation = "Because I lived to see it"
d.ActionButtonText = "Let's go"
d.Show() // perform logic in this method call
You could do the same with say Methods you add to a Window and private Properties, but then you could end up with a hell of lotta properties on the Window.
Personally, I’m fine with the way things are now, I just wish the Syntax Help area was smart enough to highlight which overloaded method you’re using, or having a tooltip popup over the parameters themselves (to show the name and type).
I search documentation and these forums for “Method parameters” and also for “Parameter names” and a few other variations.
The dialog you show is where you define the method and setup the parameters. I get that. But when you setup the parameters you add names like. mytext as string and mynumber as integer.
What I am asking is when I later call that method I setup. Is there a way to include the parameter name in the call for clarity like:
myMethod( mytext:“Here is my text”, mynumber:42 )
I find this to be very helpful in C# and in C# you can actually change the order of parameters using this. It is possible in C# to call “myMethod” like this:
myMethod( mynumber:42, mytext:“Here we go” )
Which is not the order they were defined in.
Some could argue these are not great practices, but when you do have a large number of parameters, say more than 4 it can be very handy and clear to know what is being assigned to what parameter.
Ya the highlight would be a huge help and make my desire less important. Yes it certainly can be done with the assignment of parms above. The problem is when you use this over and over you end up with a lot of lines of duplicated code. That was what I was finding by copy/paste of the dialog code everywhere I needed it.
In my base dialog method I have these parameters:
iType as MessageDialog.IconTypes, caption as string, message as string, explanation as string, actionButtonText as string, cancelButtonText as string = “”, altActionButtonText as string = “”
When calling this method I find I have to click back on the name to see what argument is next.
In my mind, what would be ideal is how some IDE’s help you select which overload Method to use (when applicable) or once you select the Method from autocomplete, the IDE writes out the parameters for you with highlighted “placeholders” in the string that you tab into and write your variable. Something like:
When the line is displayed, the first placeholder has the cursor focus, then you write the variable or text, then just “tab” to the next placeholder, until you run out of placeholders.
Unfortunately, as Scott mentioned, if your method has overloads the correct one is not highlighted (or in older versions of Xojo, not even shown). Also annoying, at least in 2021r2.1, is that you have to move your cursor backwards into the call text when typing before the signature is shown.
You can also add text in the Inspector’s Description field for the method, and this text is shown along with the signature(s):
What you’re looking for is called named parameters, and no it’s not something Xojo supports. And likely never will, as much as I’d like it. It’s not something I’d like to use every day, but it can be very handy in the right situation. And who knows, if it did exist, maybe I’d use it for all calls to make the code more self documenting.
One problem with named parameters is if you rename a parameter in the method, you also need to update all calls to it. And since Xojo allows multiple signatures, you can often solve the need for named parameters with another signature. It’s not a total solution, but it’s the best you can do in Xojo.
Another strategy - if you find yourself with methods with a lot of parameters, maybe you should create a new class with properties that you pass in instead?
// which parameter is which?
Foobar(a,b,c,d,e,f,g,h,i,j)
// a more verbose, but easier to understand way
var p as new FoobarParms
p.firstName = "Alice"
p.lastName = "Smith"
p.streetAddress = "123 Main Street"
...
Foobar(p)
This is much easier to read (and write) and understand, at the cost of requiring you to define one new class in which to send the parameters.
Using a Dictionary is a great idea, but there are some tradeoffs - most notably, you lose any static type checking that Xojo normally offers for method parameters. For example, if a parameter is supposed to be an Integer, you can pass a String instead, and the app will still compile and run (with behavior which may, or may not, be what you want).
With method parameters, this sort of mistake is less likely, although since Xojo doesn’t have named parameters, it’s possible to make other mistakes (like passing the wrong String for FirstName as String).
A Structure is almost never the right choice for anything except a Declare and some high-performance work using MemoryBlocks. For this case, use a class to hold the parameters instead.
Reasons why a Structure is the wrong choice for passing parameters to a method:
It cannot hold Strings of arbitrary length.
It cannot pass an object reference. So it cannot hold a Dictionary or a class instance, or even an array.
Strings inserted into a Structure lose their text encoding information.
button on selected code make it nice.