Re: comparative functions and "same metamethod" gotcha

On Wednesday, June 4, 2014, Andrew Starks <andrew.starks@trms.com> wrote:

On Wed, Jun 4, 2014 at 2:41 PM, Javier Guerra Giraldez <javier@guerrag.com> wrote:

i guess part of the reasons are like this: if two "objects" have
different __eq function, which do you use to compare them? it's
easiest to assume they're already different enough.

Maybe and I don't want to assert that the way that it is designed is wrong, given my limited experience. That said, I can remember one other time that I hit an issue like this and it left an impression that still gives me pause, whenever I want to use comparative metamethods.

Presumably, the limitation guards against super-ugly code that's hard to debug. One wonders if it's harder to debug wonky type comparisons or something buried in your code that fails every 1 in 2-10 times, but only inside of busted[1]?

-Andrew

[1] It may fail elsewhere. I'm not sure.

Sorry to answer my own post...

The manual says:

> Closures with the same reference are always equal. Closures with any detectable difference (different behavior, different definition) are always different.

I don't write specifications and I know that the reference manual isn't written that strictly, but we don't really have a complete definition. What is "detectable"? If a function doesn't access any upvalues and is the same function, is it always the same, or just sometimes? Is there a reason that two functions generated from the same constructor would point to the same reference when they are called from the same file, but will sometimes be and sometimes not be, when called from a different file?

I can't see where, or even how, busted is/could be broken. I see the inconsistent behavior when running the following code block, within a busted test:

local a = url("mcp://host/thread/name")

local b = url("mcp://host/thread/name/")

assert.True(a == b)

It seems like a bug in Lua or I'm not reading the correct parts of the Reference Manual.

-Andrew