Small Useful Functions

[HugoBDesigner]

You can use table.insert like in your first version:

Code: Select all

function mergetables(...)
	local ret = {}
	for i, tbl in ipairs {...} do
		for k, v in pairs(tbl) do
			if type(k) == "number" then
				table.insert(ret, v)
			else
				ret[k] = v
			end
		end
	end
	return ret
end

Yup, yours is much better

[foo0]

Anyway, I think that mixed solution is rather ugly. It doesn't overwrite conflicting number keys, but overwrites the rest of types? type(k) == "number" doesn't even mean that the key is an array index (e.g. 0, -1, 0.5 are not "valid" indexes that ipairs would respect).

It would be better to have two separate merge functions. One that only merges array parts of passed tables, with no overwrites but changed order:

Code: Select all

function mergeArrayParts(...)
	local ret = {}
	for _, tbl in ipairs {...} do
		for _, v in ipairs(tbl) do
			table.insert(ret, v)
		end
	end
	return ret
end

Second function that merges whole tables (array and dictionary parts), where last table passed as an argument wins when in conflict (Robin's version).

[HugoBDesigner]

I just thought of something: stencils and inverted stencils are basically the same thing. Why not merge them? So, I made this:

Code: Select all

setStencil = love.graphics.setStencil

function love.graphics.setStencil(function, isInverted)
	local function = function or false
	if function then
		if isInverted then
			love.graphics.setInvertedStencil(function)
		else
			setStencil(function)
		end
	else
		setStencil()
		love.graphics.setInvertedStencil()
	end
end

[micha]

The solution you suggest, makes use of a flag argument ("isInverted"). If you are striving for clean code, you should prefer two function over one function with a flag argument.
This is because calling:

Code: Select all

love.graphics.setInvertedStencil(myStencil)

is easier to read and understand than

Code: Select all

love.graphics.setStencil(myStencil, false)

Especially if you haven't looked at your code for a while, the word "false" does not tell you, what exactly it changes in the function.

Your solution would make the API shorter, because it reduces the number of functions, but it will make code less readable.

Check out the two videos:
Indie your face: Clean code
Indie your face: Clean code Part 2

[Ref]

I'm with the great micha on this but if you're hell-bent on this I would do something like:

Code: Select all

function setStencil( fn, mode )
	if fn then
		if mode == 'inverted' then
			love.graphics.setInvertedStencil( fn )
			else
			love.graphics.setStencil( fn )
			end
		else
		love.graphics.setStencil()
		love.graphics.setInvertedStencil()
		end
	end

Then your code would look like:

Code: Select all

setStencil( stencil_function )
-- or
setStencil( stencil_function, 'inverted' )
--
setStencil()

but I prefer staying with the documented Love functions.

[micha]

I haven't really thought about this before, but this is probably the reason, why the drawing functions for polygons, rectangles and circles have the drawing mode as a string and not as a boolean. I just realized that. Interesting!

[Robin]

I haven't really thought about this before, but this is probably the reason, why the drawing functions for polygons, rectangles and circles have the drawing mode as a string and not as a boolean. I just realized that. Interesting!

Plus, with booleans you can only have two options. What if, for 0.10.0, the devs want to add a 'linefill' mode that is better than drawing with 'line' and 'fill' seperately? If a boolean was used, you couldn't do that, because there are only two values available.

[szmol96]

About table merging, doesn't this one do the job?

Code: Select all

function mergeTables(addTo, addFrom)
	local a, b
	for a, b in pairs(addFrom) do
		table.insert(addTo, b) 
	end
end

[Roland_Yonaba]

About table merging, doesn't this one do the job?

Code: Select all

function mergeTables(addTo, addFrom)
	local a, b
	for a, b in pairs(addFrom) do
		table.insert(addTo, b) 
	end
end

Depends.
If the given tables are both arrays, it should do the job. But in case they are dictionnaries, the output will certainly not be the one expected.
And, about you code, the local a,b declaration is not needed.

[szmol96]

And, about you code, the local a,b declaration is not needed.

Roger that, thanks!