The Realbasic language supports the ability for methods to have different sets of parameters. One version of a method might take two integers, and another an integer and a string. This is called "method overloading" and the act of determining which overload to invoke is called "overload resolution".
When you call an overloaded method, the compiler has to figure out which one you mean. It first determines what overloads are valid to call with the given parameters. Then, it takes this list of valid overloads and counts the conversions required to invoke each one. Whichever overload requires the least amount of conversions is the winner and ends up being called. If there is no winner (i.e. there are multiple methods with the same number of conversions), the call is ambiguous and the compiler throws an error.
Now, applying this knowledge to a real world case: consider ListBox.AddRow, which has two overloads:
Sub AddRow(items() as String)
Sub AddRow(ParamArray items() as String)
and the following code:
dim v as Variant = "My string"
listBox1.AddRow( v )
When you pass in a variant, the compiler first sees that both overloads are valid (since variants can convert to arrays or strings). Next, it looks at the number of conversions required and discovers that both of them require one conversion (Variant -> String() or Variant -> String). Since the compiler can't tell which one you want, it gives back an error:
"There are several items with this name and it is not clear which one the call refers to"
In this case, the problem could have been avoided by not using variants (or saying 'v.StringValue', which makes your intention explicit). The issue with variants is that they can implicitly convert themselves to any type and often have unintended side effects. They also effectively bypass some of the compiler's type checking, delaying errors until you run your program.