"Method Pair" definition

I found a new term, “Method Pair”. The problem is it doesn’t show in the LR. It shows up (I don’t know the term maybe navigator) with Computed Property as convert to item
What is this?

1 Like

Not sure what it is designed for, but it allows me to have multiple Objects in the one class for all of Desktop, Web, iOS and Android.

Before there were Computed Properties, you could simulate them using two methods, one that would get a value, and one that would set it. For example:

Function MyProp() As String
  Return mMyProp // Get
End Function

Sub MyProp(Assigns v As String)
  mMyProp = v // Set
End Sub

In code, this is indistinguishable from a Computed Property, but these methods do not show up in the debugger while a Computed Property does.

1 Like

It now shows up? How long has that been around?

You still need those for example if you create collection class then you add a key as String parameter to both the getter and setter.

Kem, Thanks for a Good example.

For as long as I can remember.

1 Like

It’s a stylistic preference. With Method Pair they appear in the Navigator under Methods, and with Computed Properties they appear under Properties. I prefer methods, because I know they’re methods and always tend to look there instead of Properties.


There is an important functional difference as well. While in the IDE debugger, computed properties are evaluated and executed by the Debugger, as shown here:

That call to cFoo.foo.Get happened due to the debugger accessing cFoo.foo, since I had the “f” instance visible in the debugger.

1 Like

That they show up in the debugger is especially useful when the result is a calculation, not just returning the value of a private property.

1 Like

Oof. OK, forget what I said, I’m changing all my shared methods to computed properties. This is why I love this place.

1 Like

Computed properties are great, except that when you are debugging one should be careful:

  • there is no way to stop the debugger from evaulating them
  • the debugger seems to ignore breakpoints in the computed property getter when it evaluates them
  • if your getter has any side-effects, this can be maddening.

For example, in the example I showed above, my Getter increments the private property:


which is why the computed property and the private property don’t match.

But as long as your computed properties don’t do “weird” things, they seem to be fine.


And aside from the potential for side effects from the debugger:

  • Computed properties cannot be array types
  • Computed properties cannot be overridden in a subclass
1 Like

For objects on a window, computed properties also get a default value assigned to them by the inspector, even if no inspector behavior has been assigned. This can be maddening because it happens after your constructor and opening event, so setting your own default becomes hard. Plus, if the setter triggers other functionality, these automatic defaults will trigger that too.

I use lots of computed properties because I like the organization. But method pairs are far more robust with far fewer quirks.


There is another aspect:

The method pair can be part of an interface while a computed property cannot be part of an interface.

1 Like


I have long converted simple variables into Computed properties in order to simulate ‘watch when changed’ while debugging (because Xojo doesnt have that)

BUT: if these variables are used intensively (say inside a long loop), then the overhead of using a method can be significant for performance. I revert them to simple properties after I’m done testing, if they don’t need side effects.

1 Like

I think I got bitten by this long ago and probably a reason I gravitated to method pairs.