lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Sat, Jan 28, 2012 at 05:25, Matthew Wild <mwild1@gmail.com> wrote:
> On 28 January 2012 06:29, HyperHacker <hyperhacker@gmail.com> wrote:
>> On Fri, Jan 27, 2012 at 06:39, Matthew Wild <mwild1@gmail.com> wrote:
>>> On 27 January 2012 11:21, HyperHacker <hyperhacker@gmail.com> wrote:
>>>> On Fri, Jan 27, 2012 at 04:20, Luiz Henrique de Figueiredo
>>>> <lhf@tecgraf.puc-rio.br> wrote:
>>>>>> to make this work, you need to wrap the lookup:
>>>>>
>>>>> Or do
>>>>>        params = {["1"]='file.c', ["2"]='file.o'}
>>>>>
>>>>
>>>> Well yes, but that isn't always feasible, e.g. with the {...} example.
>>>
>>> setmetatable({...}, { __index = function (t, k) return rawget(t,
>>> tonumber(k)); end })
>>>
>>> Regards,
>>> Matthew
>>>
>>
>> That's not really much simpler, and still assumes you can modify the table.
>
> Then pass a closure instead that implements the same logic. No need
> for a metatable then.
>
>> I feel like the point has been largely missed. :|
>
> It hasn't, but I doubt anyone agreed with it being part of Lua itself.
> Converting from a string to a number is a special case, specific to
> your current problem. But that's fine, Lua already gives you the
> flexibility to do whatever you want. You've already had multiple
> solutions to your problem. If this is a common one for you, wrap gsub.
> You can pass it a table, or a function. This is *exactly* why it
> allows you to do that.
>
> If you want some concrete reasons your logic shouldn't be part of Lua
> itself, consider that it's going to be rather surprising behaviour to
> people mixing strings and numbers as keys in tables. And which one
> should be tried first? Should all numbers be tried? or only whole
> integers? Negative numbers? 0? You're suddenly adding a dozen lines of
> code to Lua that no-one has asked for before, just for you. It's not
> going to happen.
>
> Regards,
> Matthew
>

I thought I already addressed these points in my first post:
> print(("gcc %1 -o %2"):gsub('%%(%d+)',
>    function(n) return params[tonumber(n)] end))
(i.e. the logic is pretty simple, just having to do it every time
makes your code a little less pretty)

> and if you wanted to remain compatible with the current behaviour...
> print(("gcc %1 -o %2"):gsub('%%(%d+)',
>    function(n) return params[tonumber(n)] or params[n] end))  --ugly! (and doesn't account for params[tonumber(n)] == false)
(i.e. even keeping compatibility is only an extra two statements, it
just looks ugly)

> I imagine this is a fairly common use,
(surely I'm not the only one who's ever encountered this?)

As for which comes first, I'd hate to imagine what kind of application
that can be a problem for, that's mixing "1" and 1 in the same
table...

I suppose it'd be slightly more complex in C, but I doubt more than 6
lines, and ultimately line count is a rather poor metric. (I can write
an interpreter in a few dozen lines of C, but the language it
interprets is going to be quite a pain to use...)

-- 
Sent from my toaster.