[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade)
- From: Coroutines <coroutines@...>
- Date: Mon, 24 Mar 2014 22:38:02 -0700
On Mon, Mar 24, 2014 at 9:41 PM, Tim Hill <drtimhill@gmail.com> wrote:
>
> On Mar 24, 2014, at 9:32 PM, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
>> 2014-03-25 5:13 GMT+02:00 Andrew Starks <andrew.starks@trms.com>:
>>
>>> I also agree that ".." should always call __tostring, even on (especially) tables.
>>
>> I don't agree. Lua should "not know what to do" so that a metamethod will be
>> looked for. Otherwise we can chuck away the __concat metamethod.
>>
>
> I agree, and your example highlights the deeper difference between operator metamethods and coercion metamethods. I'd hate to see Lua ending up as messy as C++ where figuring out which function was called involves looking at templates, signatures, automatic casts etc etc .. (shudders).
>
> I think __tostring() should get invoked ONLY when tostring() is explicitly called.
>
> --Tim
>
>
Yesterday I was thinking about how it would be nice if you could
define a metatable for the function type (through debug.metatable)
where __call is respected -- you could do a nicer form of backtracing
functions if you could wrap the call to each function globally (rather
than hooking them). The problem with this is your function would also
trigger __call, as it too is a function. A recursive __call obviously
leads to stack overflow. This led me to think maybe it would be
useful if you could set a marker before and after a section of code
where between which no metamethods will be called. Rather than have
rawget/rawset() you'd have something like:
meta:no
local t = whatever.index
t()
meta:yes
Disregard the odd syntax, but the idea (I think) is an interesting one
-- rather than having an expanding set of raw*() functions.
More to the point: I think it'd be a bad idea to not make use of a
__tostring() if it is defined. I'd be glad to see .. The only reason
you'd want to avoid one is if you want the stock raw object string
representation and (imo) that is less common if you're defining
__tostring()'s on things. Just thought I'd throw my hat in and say
coercion is nice, otherwise I'd be writing C. Why set up for coercion
if you don't think the language should use it? Btw, Python has a nice
way of separating these: repr() and str()
Maybe we need coercion everywhere and a rawstring() :p
- References:
- [ANN] Lua 5.3.0 (work2) now available, Luiz Henrique de Figueiredo
- Re: [ANN] Lua 5.3.0 (work2) now available, Egor Skriptunoff
- Re: [ANN] Lua 5.3.0 (work2) now available, Roberto Ierusalimschy
- Re: [ANN] Lua 5.3.0 (work2) now available, Andrew Starks
- Re: [ANN] Lua 5.3.0 (work2) now available, Roberto Ierusalimschy
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), katlogic
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Roberto Ierusalimschy
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Hisham
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Rena
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), William Ahern
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Andrew Starks
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Dirk Laurie
- Re: [ANN] Lua 5.3.0 (work2) now available (number coercion holy crusade), Tim Hill