Keyword as function name (was: Table dot number?)

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Keyword as function name (was: Table dot number?)

Michal Kottman
On 28 October 2011 17:53, Stefan Reich
<[hidden email]> wrote:

> On Fri, Oct 28, 2011 at 9:28 AM, Miles Bader <[hidden email]> wrote:
>> HyperHacker <[hidden email]> writes:
>>> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
>>> especially alongside those like the first line.
>>
>> c'mon, that's not _that_ bad, especially given that it will only
>> rarely need to be used.  It's arguably even a good thing, since it
>> explicitly makes the point "hey this function name is a keyword, so be
>> careful..."
>
> Yeah, it sounds really smart to use "for" as a function name in your
> Lua code :-))
>
> (Hilarity ensues!)

Sometimes, you cannot avoid it. For example when generating a 1-1
binding to a library which uses methods named as Lua keywords. An
example of this is the Qt library - 19 of it's classes have a method
named 'end' [1], which you cannot call using Lua's syntax sugar. You
have to call it as follows:

    painter['end'](painter)

Does someone propose an elegant way to handle this? :)

[1] http://doc.qt.nokia.com/4.7/functions.html

Reply | Threaded
Open this post in threaded view
|

Re: Keyword as function name (was: Table dot number?)

Pierre Chapuis
On 28.10.2011 18:59, Michal Kottman wrote:

> Sometimes, you cannot avoid it. For example when generating a 1-1
> binding to a library which uses methods named as Lua keywords. An
> example of this is the Qt library - 19 of it's classes have a method
> named 'end' [1], which you cannot call using Lua's syntax sugar. You
> have to call it as follows:
>
>     painter['end'](painter)
>
> Does someone propose an elegant way to handle this? :)

     painter._end = painter['end']

--
Pierre Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: Keyword as function name (was: Table dot number?)

Tomás Guisasola-2
>>  Sometimes, you cannot avoid it. For example when generating a 1-1

>>  binding to a library which uses methods named as Lua keywords. An
>>  example of this is the Qt library - 19 of it's classes have a method
>>  named 'end' [1], which you cannot call using Lua's syntax sugar. You
>>  have to call it as follows:
>>
>>      painter['end'](painter)
>>
>>  Does someone propose an elegant way to handle this? :)
>
>    painter._end = painter['end']
  You can use uppercase:

for k, v in pairs(painter) do
  if type(k) == "string" and type(v) == "function" then
  local K = k:gsub("^(.)", string.upper)
  painter[K] = v
  end
end
assert(painter['end'] == painter.End)

  Or, if you prefer, do it only for the keywords...

  Regards,
  Tomás
Reply | Threaded
Open this post in threaded view
|

Re: Keyword as function name (was: Table dot number?)

Dirk Laurie-2
In reply to this post by Michal Kottman
2011/10/28 Michal Kottman <[hidden email]>:

> On 28 October 2011 17:53, Stefan Reich
> <[hidden email]> wrote:
>> On Fri, Oct 28, 2011 at 9:28 AM, Miles Bader <[hidden email]> wrote:
>>> HyperHacker <[hidden email]> writes:
>>>> funcs['for'] = function(...) doStuff() end --OK, but harder to read,
>>>> especially alongside those like the first line.
>>>
>>> c'mon, that's not _that_ bad, especially given that it will only
>>> rarely need to be used.  It's arguably even a good thing, since it
>>> explicitly makes the point "hey this function name is a keyword, so be
>>> careful..."
>>
>> Yeah, it sounds really smart to use "for" as a function name in your
>> Lua code :-))
>>
>> (Hilarity ensues!)
>
> Sometimes, you cannot avoid it. For example when generating a 1-1
> binding to a library which uses methods named as Lua keywords. An
> example of this is the Qt library - 19 of it's classes have a method
> named 'end' [1], which you cannot call using Lua's syntax sugar. You
> have to call it as follows:
>
>    painter['end'](painter)
>
> Does someone propose an elegant way to handle this? :)
>

If you would have used `painter:end()` a lot:

    local painter_end = function() return painter['end'](painter) end

If not, it's a non-issue.

Dirk