Re: Suggestion for 5.3: import() for creating a "slew" of locals

[Rena <hyperhacker@...>]

On Sun, Nov 17, 2013 at 3:33 AM, steve donovan <steve.j.donovan@gmail.com> wrote:

On Sun, Nov 17, 2013 at 10:00 AM, Sir Pogsalot <sir.pogsalot@gmail.com> wrote:
> - localize() instead of import() so it doesn't get confused as having some
> function like require()
> - I'm not saying let's get rid of all the 'local a = module.a' lines, just
> provide this for when you need to create a lot of locals

This is definitely one of those feature requests that happens every
few years!  And yes, 'import' is confusing by association with Python.

But the point to understand is that this must be a purely _static_
operation at compile time. So implementing something like 'using
table.*' hits the problem of determining the contents of 'table' at
compile time.  So it would have to be an explicit list of entries to
localize, and understood as syntactical sugar for all those pesky
'local insert = table.insert' statements.

The issue then is that Lua is a 'reduced carbohydrates' language that
does not provide much sugar in the product, expecting users to add
their own.

Personally, I think such a construct would be useful, but unlikely to
get much traction.

steve d.

As someone who strongly dislikes repetition, I can see it being nice to be able to write something like:
local insert, concat from table

but then I feel like I'd rather name them tinsert and tconcat to make it clearer where they came from, and then I'd have to specify the original names to extract from table, and then we're back to:

local tinsert, tconcat = table.insert, table.concat
which still repeats 'table', but I don't see a good way to avoid that without a severe loss of clarity.

--
Sent from my Game Boy.