I accidentally used the same name twice for a method and found them “nested” in the Methods list. I tried again and found I could create a small nest of methods “inside” the top method with a clickable arrow on the left to hide the “inside” methods.
I can’t find any documentation on this but I would find it very useful. I have several methods with names beginning get_ set_ build_ etc and it would be much tidier and easier if I could make them all sub methods of a main method.
Is this possible?
Yes, that’s called overloading. It allows you to have the same method name with different parameter lists. So for example you could have a class with a method that took a date object as a parameter. You could then create the same method name with a DateTime object instead.
The types and number of parameters is the distinction. You cannot have a method that takes a pair of integers and then a second one that also takes a pair of integers, even if the parameters had different names. That would cause the compiler fail to resolve which function to call in a given instance.
For get / set style methods you could look at computed properties it works like a property but provides a pair of methods for getting and setting the value.
The new documentation is nice, but it lack many things, too many things…
It wasn’t hard to find, I simply searched for “Overloading” and it was the first result.
Thanks, Ian, that’s interesting but I don’t think I’m likely to use it much. What would be nice would be to be able to create folders inside the Methods list called “Gets”, “Sets”, “Builds” etc and inside the Properties list folders called “Arrays”, “Booleans” etc. I see Xojo lets you create folders but you can’t put them inside the Methods list or inside the Properties list and they won’t accept Methods or Properties.
Would this be so difficult to do? It’s just a matter of keeping the interface tidy and organised. I’ve started creating Modules with Properties and Methods but this means all the Methods and all the properties end up in different places and you have to remember to keep putting winMain. in front of every reference to a Property.
I understand that many applications tend to have a variety of different windows but mine generally have an overall controlling window that has most of the Properties and most of the Methods so it starts to create organisational headaches.
I’m not sure I follow they logic of storing all the gets and sets in different places. I’m guessing you have something like a property called Aardvark (just a random meaningless word in this context). You have a getAardvark, setAardvark and a buildAardvark. If that is the case I’ve switched to actually having things called AardvarkGet, AardvarkSet and AardvarkBuild. That way you can scroll to the Aardvark section and adjust any of the parts of Aardvark all in the same place. If something in the nature of Aardvark changes you no longer have to navigate to three different parts of the methods list to adjust it.
I’m still thinking that a get / set pair could perhaps be better arranged as a computed property. This would provide you with a property called Aardvark that would then fold out to show get and set methods. Not sure that would work for your design.
with computed properties you move from code like:
somevariable = myWindow.get_Aardvark
myWindow.Aardvark = 10
somevariable = myWindow.Aardvark
An alternative is for your collection of related methods to be a class (in my example AardvarkClass) you then have a property called Aardvark of type AardvarkClass. You can then do things like:
Somevariable = myWindow.Aardvark.getvalue
Or what ever makes sense in your context.
Overloading gives you the ability to create getters and setters without having different method names so they can always be found together and collapsed to take up less space in the navigator. You can also use overloading for the ability to use a single method name that takes different parameters.
As an example, add a property to a window/module/whatever as
Private Property isAardvark As Boolean.
Now you can add the overloaded getter and setter methods:
Public Sub Aardvark(assigns value as Boolean)
isAardvark = value
Public Function Aardvark() As Boolean
You can then use them as:
var myAardvark as Boolean = Aardvark 'Gets the value of isAardvark
if myAardvark = False then
' Do something
Aardvark = True 'Set the value of isAardvark
For an example of parameter type overloading, here are a couple of methods that will allow you to write code based on what datatype is passed.
Public Sub Platypus(value as String)
MessageBox( "Platypus is a String!" )
Public Sub Platypus(value as Boolean)
MessageBox( "Platypus is a Boolean!" )
Which you can then call as:
Platypus( "Hi" )
Platypus( False )
Thanks for the advice, simply reversing the order of the words has helped tidy things up a lot. Not sure I can quite get my head round all the Aardvarks and Platypuses, though