Some years ago, Xojo introduced the ability to use Computed Properties, something that is present in other programming languages too and is based on the use of dedicated methods to assign and retrieve the property value itself. So, in other programming languages, the first of these dedicated methods (or functions), the Setter, is the one invoked every time we want to modify the value of the associated property, while the Getter method is the one used from our code to retrieve the associated value. The Object-Oriented Programming (OOP) concept found behind this feature is Method Overloading. Nevertheless, let’s make clear that Xojo Computed Properties are not methods. They aren’t! But they make our life as developers much easier compared with regular Properties.
As you can see in the screenshot, below the property name we find both methods: Get and Set. ‘Get’ is automatically invoked (and showed by the Debugger) every time we write for instance:
Dim textVar As String = myProperty
While ‘Set’ is the one automatically invoked every time we want to assign a new value to the property, using, for instance, a sentence like:
miPropiedad = MyTextField.text
But if you try to execute these examples just as they are, you will get errors from the Compiler. The property itself doesn’t exists yet, just this wireframe or umbrella! When we create a new Computed Property this way, we are creating the wrapper but still have to define the real container (the property itself) in charge to store the values processed by Set and Get. This is something we can fix very easily; just a matter of adding a new property and defining its scope as private. This way we will be sure that no other object can directly access the property. The only way to get and/or set its value would be from the Computed Property methods previously created.
In fact, the way you can more clearly see the relationship between a regular property and the Calculated Property wrapper is by defining the regular property in first place. Add a new property, select it from the Project Browser, access the contextual menu and select the ‘Convert to Computed Property‘ option, as showed in the following screenshot:
As result, you’ll find that Xojo’s IDE has included the wrapper previously seen, modifying the original property’s name to include the “m” character as prefix. At the same time, the scope will change to Private too.
The magic behind Set and Get
Behind of the sugar syntax they provide, the real power found in Computed Properties, when compared with regular ones, resides in the code that we can write on both, and that will be executed just before we retrieve the property value or just before we make a new assignation to it.
Following with our example, if we would be using the property to store a person name, we could use Set on such property to provide a default value if the received one is an empty string:
Set (Value As String)
If Value = "" then mMyProperty = "New User"
On the other hand, we could use the Get on the property to retrieve the associated value using a predefined format. In our example, this could be getting the name using TitleCase (I know, I know⦠we can do this from the Set too, but just wanted to illustrate the topic exposed).
Get As String
Return mMyProperty.Titlecase
Method Overloading
Did you know Computed Properties always were feasible in Xojo? I mean, what we find behind the Computed Properties on Xojo’s IDE is a help to us as developers in order to simplify the process (and from an organizational point of view of our code).
The truth is that we always could achieve the same results (and still is possible) using the feature available in every Object Oriented Programming language, as is the case of Xojo! I’m referring to Method Overloading. This doesn’t mean that you have to choose between using Computed Properties or Method Overloading⦠the point here is to introduce what Method Overloading.
Method Overloading is the ability we have to define multiple methods using the same name, as long as their parameters types and/or number varies, and/or the type returned from the method itself. So, it’s time to see how we can achieve the same results of a Computed Property using Method Overloading.
Start adding a new property via Insert > Property. Define its type (String in this example) and its scope as Private. Make sure to add the “m” character at the beginning of the property name! (in fact you can use any other character, but we use the “m” as convention).
Now it’s time to create our Setter method. For that, use Insert > Method on the same project item where you created the property. Use the same name of the property without the initial “m” as the Method name, and write the following code in the Parameters field on the Method’s Inspector Panel:
Assigns Value as String
Leave empty the Return Type field (type returned by the method) and select Public as the Method Scope.
The ‘Assigns‘ keyword provides the syntax sugar to use the equal symbol (“=”) on the parameter pass to the method. This way, we can invoke our method (myProperty on the example) as follows:
myProperty = "New Value"
Does it seems like we are not calling a method but making an assignation to a Property?
Let’s create the method in charge of the Getter and, for that, we will repeat the same steps involved in the creation of a new method. When done, using the same name, you’ll see that the Project Browser will group together both methods. In this case, as we want to define the Getter, we don’t need to define the parameters, just the returned type (String for this example).
This is the way it will look in the Project Browser:
As we have previously seen, the method overloading is possible because they differ in the provided parameters and/or returned type, despite they use the same name. That way, the Compiler will know exactly which one has to execute on runtime based on such information.
Done! You’ve learned what Computed Properties are and how they work from the OOP side of the Xojo’s language.
Finally, probably you want to know too that:
* Computed Properties appear in the debugger and cannot be overloaded on subclassses
* Getter/Setter method overloading does not appear in the debugger, but can be overloaded on subclasses and specified in interfaces.
You can watch the video (in Spanish only) that talks you though this example.
Javier RodrÃguez has been the Xojo Spanish Evangelist since 2008, he’s also a Developer, Consultant and Trainer who has used Xojo since 1998. He is in charge of AprendeXojo.com and the developer behind the GuancheMOS plug-in for Xojo Developers and the Snippery app, among others.
More Posts From Javier:
