Re: comparative functions and "same metamethod" gotcha

[Coda Highland <chighland@...>]

On Wed, Jun 4, 2014 at 9:05 PM, Andrew Starks <andrew.starks@trms.com> wrote:
>
>
> 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

I THINK (and I'm not certain) that differing line numbers in the debug
info is enough to mark them as "different". I think "similar enough"
essentially refers to two functions being instantiated by different
iterations of the same line of code.

/s/ Adam