So I found a bug, after many months or years or whatever it is. I
can't remember the last bug or when it happened...

The funny thing about this bug, is that it didn't produce wrong
results, it only slowed things down. So that's why it wasn't noticed
till recently!

Also, it didn't slow many things down, as... in terms of CPU, it
probably took made the average app using ElfData about 1% slower...
but still... it's there, and in some unlucky cases, it could make an
app be 3x slower.

OK... so what is this bug? Basically, RB is silently doing this:

dim s as STRING = ElfData.Operator_Convert( ElfData2 )
ElfData1.Operator_Compare( s ) // operator_compare is only defined
against strings

instead of this:

ElfData1 <> ElfData2


Use this code to demonstrate:

dim c as new ElfDataCentralTrapper

if Elfdata = ElfData then
Beep
MsgBox "oh dear"
end if


and create this class:

class ElfDataCentralTrapper super ElfDataCentral
event ElfDataOperatorConvert()
Break
End event
end class


You will see the breakpoint fire! ElfDataCentral is a class I made for
trapping events like operator_convert, which could be a problem for
code. I hadn't imagined it being THIS kind of a problem however!!! I
only imagined people doing things like this:

dim e as ElfData

e = "hello"
if e.Instr( "ello" ) > 0 then
DoSomeCode
end if

And ElfDataCentral helping with those kind of operator_convert
situations.

But this one is ridiculous.

I guess I imagined that RB would "do the right thing". But that might
be too much to ask for.

"The right thing".... clearly, to me... would be to use the normal
operator... instead of applying operator convert to get the job done.

In theory, I could also create operator_compare for ElfData against
ElfData... so it's not just string against ElfData. But I tried that
in the past, and it created other problems. Basically... if I try to
do this:

if e = nil then
CodeHere
end if


That would crash, because it tries to do this instead: if
(nil).Operator_Compare(nil) = 0 then

So you get nilobjectexceptions :(

Yeah... dumb.


Oh well.

Either 1) RB2009 has fixed the behaviour of nil used in
operator_compare, and I can upgrade my code.
Or 2) I gotta remove ElfData.Operator_Compare
Or 3) Leave ElfData running much slower than it should, which kind of
defeats the purpose of ElfData.


Just warning people in case they have an idea if they want ElfData to
run faster than it used to, but at the expense of some old code
needing to change from this:

if e <> "hello" then

to this:

if e.ToString <> "hello" then