Re: overriding string __eq as in: if {} == "string"

[Andrew Starks <andrew.starks@...>]

On Tue, Jun 16, 2015 at 2:01 PM, Andrew Cagney <andrew.cagney@gmail.com> wrote:
> On 16 June 2015 at 13:04, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>> 2015-06-16 17:42 GMT+02:00 Andrew Cagney <andrew.cagney@gmail.com>:
>
>>> The objective here is to fully integrate my objects into Lua.  That
>>> is, expressions such as:
>>>   o = "string"
>>>   i = i+1
>>>   if i == 1 or o == "string" then
>>
>> The first line creates a value of type string and stores it in _ENV.o
>> unless you have overridden __newindex in _ENV, a risky thing to do.
>> And as the docs state, __eq will not be invoked in the third line.
>
> Yes, I'm taking that risk. __index and __newindex are overridden.
> That way things like:
>
> print(a,b)   -- global __index creates values for "a" and "b" on-demand
> a = b        -- update "a" with b using __setindex
>
> work the way I'd like.
>
>> What you can do is to redefine stuff not normally used for strings.
>> E.g. you can redefine string_mt.__not to be a constructor for your
>> wrapper type and string_mt.__xor and to be your intended __eq.
>> Then the following will work:
>>
>>    o = ~"string"
>>    i = i+1
>>    if i == 1 or o ~ "string" then
>
> or as a first cut:
>
>     o == ~"string"
>
> while not, from my personal pov, ideal it does let me move forward.
>
> Andrew
>
>>
>

Hey Andrew,

>From my experience, overriding the basic types is not as awesome as
making new "objects" with tables. You can make  string-like object by
overloading __concat and __tostring and __eq.

Overloading string is something that I've had great fun, but I have a
Url object that starts life as a table and it seems to work pretty
well.

-Andrew