Re: Local as table
[
Date Prev][
Date Next][
Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: Local as table
- From: Miles Bader <miles@...>
- Date: 2013年2月23日 12:49:50 +0900
James Graves <james.c.graves.jr@gmail.com> writes:
> One of my goals with this design for an import statement is to
> eliminate a lot of the boilerplate code you normally need to achieve
> what we're talking about.
>
> I'd like to just have an import statement at the top of the module,
> and a return at the end. The exported functions could just be
> declared without the 'local' keyword, and the non-exported functions
> with 'local'. There would not be a need to build a table to return
> the exported functions.
>
> It could be more concise than how it is normally done now.
That particular boilerplate, though, is so minimal, that I'm not sure
it's worth much effort to eliminate.
Moreover, I think explicitly using the module name in exported function
declarations increases program clarity, so not doing so might even be a
considered a _bad_ thing...
e.g.
local blarg = {}
function blarg.foo () ... end
function blarg.oink () ... end
return blargh
Is _more clear_ than a version which leaves out the "blarg." bits.
-miles
--
永日の 澄んだ紺から 永遠へ
- References:
- Local as table, Andrew Starks
- Re: Local as table, steve donovan
- Re: Local as table, James Graves
- Re: Local as table, Justin Cormack
- Re: Local as table, James Graves
- Re: Local as table, steve donovan
- Re: Local as table, James Graves
- Re: Local as table, Andrew Starks
- Re: Local as table, James Graves
- Re: Local as table, Andrew Starks
- Re: Local as table, James Graves