Method Overloading Issue

I have an issue that looks like it started in 2014 Release 3. I have a project with two modules (and classes) that each overload the str() method with arguments specific to each class. Within these overloaded methods there are regular calls to str() with integer and float arguments. In release 3, these calls are calling the overloaded method instead of the internal method causing a circular calling situation resulting in a stack overflow. Release 2 and prior releases seem to work as I intended. Could this be a bug introduced with release 3 due to operator_convert changes?

To be sure that I am explaining this correctly, I have the following methods:

str(apmint) and
str(apmfloat)

where apmint and apmfloat are two classes for two new numeric types.

In the two above methods there are calls to str() with XOJO float and integer arguments.

It appears that in release 3 the str() calls with float and integer arguments are calling the str(apmfloat) overloaded method. This did not happen in release 2 and prior.

If you analyze your project, are there any warnings about name lookup changes?

Joe, no warnings about lookup changes, only a few unused variables which should not be a problem.

Please file a bug report.

Joe, I filed a bug report. Not sure that I explained it right in the bug report but I did include a slimmed down project that exhibits the problem in release 3 and not prior versions.

feedback://showreport?report_id=37357

Thanks for filing this. The only bug here is that the compiler isn’t reporting this as a name lookup change when analyzing the project.

Does that mean that I can’t overload str() for new classes or I was doing it wrong?

Joe, never mind I saw your explanation in the bug report. Thanks.

Joe, when I change the offending str() methods to Global.Str() in the sample project I get “this item does not exist errors”. Is there another change needed?

The other option is to use REALBasic.Str

Ah, right. This is correct answer.

Having looked at the project attached to the case, I’m a little surprised at the answer here.

The function…

[code]Function str(num as apmfloat_module.apmfloat) As string
// convert an apmfloat to a string and format it to make it more manageable (breaking it into lines of fixed length)

Return num.to_string()

End Function[/code]

… clearly has a very different signature to what is defined for REALbasic.Str().

According to the docs REALbasic.Str() takes a value param of “Numeric, Boolean, Date, or Color”, the usage of Str() within apmfloat class is definitely passing a numeric rather than apmfloat to Str() so surely the only signature match is the version of Str() outside of William’s apmfloat_module?

Is it maybe the case the framework version of Str() actually accepts more than just “Numeric, Boolean, Date, or Color” and there is simply a doc bug?

I’m certain the issue here is that it has to do with the use of STR and that there is an operator convert that takes a variant

in operator_convert there are two lines
d = num.DoubleValue
s = str(d) // <<<<<<<<<<<<<<

and

i = num.Int64Value
s = str(i) // <<<<<<<<<<<<<<<

that end up calling the modules STR since
s = str(d)
ends up being interpretted as meaning
s = Str( apmFloat.operator_convert( double ) )
and the same for the other

So when you run and press the button you end up with a stack overflow because it perpetually calls itself doing the converts etc quite dutifully & calling str which calls convert and so on …

disambiguating the use of REALbasic.Str fixes that ambiguity

Joe, Norm, thanks for the help! I changed all the instances of str() with Realbasic.str() for all cases with XOJO integer and float arguments and all is well now.

BTW, I tried to look up the Realbasic keyword in the language reference and did not find it. It this an undocumented feature or did I miss it.

Its existed for … 7 or 8 years
One of the first namespaces in the framework … hence the name
Funny - its existed so long I never even noticed its NOT mentioned in the language reference on the modules page
Go figure

I believe it was in the User’s Guide before. Don’t know about now. Wouldn’t expect to see it in the Reference.

[quote=152954:@Norman Palardy]Its existed for … 7 or 8 years
One of the first namespaces in the framework … hence the name
Funny - its existed so long I never even noticed its NOT mentioned in the language reference on the modules page
Go figure[/quote]

Interesting, that notion of Realbasic.str() vs str(). Where can I find out more about the Reabasic namespace methods ?

Odd but true despite it having existed for a very long time there’ nothing in the LR about it
Seeing what I can do to correct that

In the IDE type Realbasic. and press the TAB key.

True
It is just a namespace with the global methods in it so they can be disambiguated (like in this case)
But I think it should be in the LR