[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Suggestion: syntax sugar for object methods inside table constructor
- From: Mason Bogue <scythe+lua@...>
- Date: Tue, 1 Jun 2021 18:15:37 -0400
The problem with this syntax (which has been proposed before) is that
it's not, in fact, truly consistent with the method definition syntax
used for "OOP in Lua". Particularly:
my_obj = get_obj()
function my_obj:do_stuff(arg1, arg2) --[[ code ]] end
versus
my_obj = {
function do_stuff(self, arg1, arg2) --[[WARNING: signature is
different!]] end
}
As such it was decided long ago that the apparent similarity is not
worth the risk of being misleading. Also, as a language, Lua prefers
to use keywords to delimit code blocks, whereas declaring methods in a
table constructor means using braces -- and worse, COMMAS -- to
delimit code blocks. This is ugly, so we might as well make the whole
thing ugly.
If you want to declare methods "nicely", do it the first way. It works fine.
Best,
Mason
On Tue, Jun 1, 2021 at 4:02 PM shankusu2017 <shankusu2017@gmail.com> wrote:
>
> local func = function() ... end
> looks nicer than...
> local function func() ... end
>
> and more beautiful
>
> Egor Skriptunoff <egor.skriptunoff@gmail.com> 于2021年6月2日周三 上午2:34写道:
>>
>> On Tue, Jun 1, 2021 at 5:58 PM Paul Ducklin wrote:
>>>
>>> local func = function() ... end
>>> ...looks nicer than...
>>> local function func() ... end
>>
>>
>> It seems there exist two groups of Lua users.
>>
>> 1) First group - users who prefer to emphasize that Lua functions as just regular objects.
>> The "natural inclination" of 1nd group users is to use the "function" keyword for producing R-values only.
>> They would be happy with named-functions-syntax completely removed from Lua (despite the small problem with local recursive functions).
>>
>> 2) Second group - users who prefer to write Lua scripts in a way similar to programming in other languages.
>> The "natural inclination" of 2nd group users is to always see a function's name after the keyword "function".
>> From their point of view the existing Lua syntax for defining local and global functions is nice.
>> But when they try to define a function inside an object they are forced to use incongruous "name=function" syntax.
>> Mixing the two styles in one Lua program is ugly.
>>
>>
>>>
>>> I don’t understand the “problem” you are trying to solve
>>
>>
>> The problem is: the users from 1st and 2nd groups do not have "equal rights".
>> The former are quite happy in the current Lua, they can always follow their favorite "all-functions-are-anonymous" style.
>> The latter are unable to always follow their favorite "each-function-is-defined-with-a-name" style.
>>
>> Please note that most Lua newcomers are in the second group.
>>