A nice little trick

Some of you may know this, but you can “unpack” a table into a list like this, so the items can be used as function parameters

--is the same as

--and you can unpack into the end of a list
--is the same as

--but if there are any parameters after your unpack statement, then only 
--the first table item is used (this is deliberate, I forget the reason)
--is the same as

Note the built in reference incorrectly tells you to unpack tables with tableName.unpack(). The correct syntax is unpack(tableName).

You can unpack vectors the same way, but the syntax is vectorName:unpack().

fancy trick?how about a complicated table or color ?matrix?

I love this trick! It will work with anything stored in a table. Although I’m not sure what it does with key/value tables…

This sounds right up my street @ignatz for level design. Is it possible to store code for ‘Waves’ of aliens for my shoot em up in another class that has the table and call that? Does the class have to be placed on the canvas for me to access that class’ table data?

I ask as I’m looking to keep all the level data out of the main file to keep it as light as possible for processing speed and only call the ‘wave’ data when I need it

@Ignatz I’m not sure that makes it easier or not. The receiving function would need a variable for each table entry SomeFunction(a,b,c) or using SomeFunction(...) with arg={...} would be about the same as SomeFunction(tab) and reading the table tab. Passing the table followed by other variables wouldn’t have a problem of the missing variables in the table.

@dave1707 - a handy use is in translate and camera



also possible with vectors? - translate(VEC2:unpack())

Actually, I never noticed the vector:unpack(). That’s very handy. It’s hard not to run into functions that seem more appropriate for points and ones that require positions. Though, it would be much nicer if you could unpack and obtain the full list in a set with other attributes.

It’s useful for making a shallow copy of tables (ie table must be one-dimensional). There is now the table.move command, but I find this method easier to use (less parameters needed)

    a = {10, 15, 20}
    b = {unpack(a)} --shallow copy (nb 1 dimensional)
    c = a --just a pointer, not an independent copy
    a[2] = a[2] + 100
    print(unpack(a)) --10, 115, 20
    print(unpack(b)) --10, 15, 20
    print(unpack(c)) --10, 115, 20

That shallow copy usage is very nice, I hadn’t thought of that… :slight_smile:

@yojimbo2000 very useful didn’t thought of that either … cool!

table.unpack can take 2 extras parameters, the start and end index to unpack from and to. ie: make a sliced copy of a table.

a = {1, 2, 3, 4, 5}
b = { unpack(a, 1, 3) }
print(b) -- > { 1, 2 , 3 }
c = { unpack(a, 3) }
print(c) -- > { 3, 4, 5 }

The table.move method is also very handy :slight_smile:

What about performance? Any need for concern in the draw loop?

Unpack is a little slower than doing it yourself, but not by much, in my tests.

If you need utmost performance, vector arithmetic is the thing to optimize. But most of the time, it is plenty fast enough.

Thanks, was more interested for understanding, seemed unpack would have to be slower if it’s a real call. Speed has always been fine, and the Pro is amazing.

Pro? Lucky fellow :-bd

can we use this with color() ?


t = { r=123, g=123, b=123, a=255 }
self.drawColor = color(unpack(t))

@matkatmusic The way you show doesn’t work, but this does.

function setup()
    t= {r,g,b,a }
    drawColor = color(unpack(t))

function draw()

what are the results of calling unpack on a table with named keys? if you print( unpack({r=255,g=255}) ) nothing is printed.