LÖVE

I like the look to the "Available since LÖVE" box, pretty smooth. However, bunching up functions with multiple meanings for the parameter list is something you'll have to be very careful about. In the case of love.keyboard.isDown, there's only one meaning to the function, so it's probably okay to bunch it there (or list the other ways to use it as one section), but with other functions that can take a wide variety of parameter, please keep it separated out.

Inny wrote:In the case of love.keyboard.isDown, there's only one meaning to the function, so it's probably okay to bunch it there (or list the other ways to use it as one section), but with other functions that can take a wide variety of parameter, please keep it separated out.

And doing it sometimes this way and sometimes that way is awfully inconsistent, let's not do that.

Robin wrote:

Inny wrote:In the case of love.keyboard.isDown, there's only one meaning to the function, so it's probably okay to bunch it there (or list the other ways to use it as one section), but with other functions that can take a wide variety of parameter, please keep it separated out.

And doing it sometimes this way and sometimes that way is awfully inconsistent, let's not do that.

Right, right. Consistency is important. What I was saying is that the function( manditory [, optional] ) style isn't necessarily a problem, since it's how functions are listed in the Lua 5.1 manual.
For instance, table.sort (table [, comp]).
On the otherhand, what is this i don't even table.concat (table [, sep [, i [, j]]]).

Seeing as how the Wiki is our primary documentation for love's API, it's more important to get this right than pretty, so use the best judgment that money can buy.

Inny wrote:what is this i don't even table.concat (table [, sep [, i [, j]]]).

Lol I see your point (took me a bit to figure it out) but this is it.
Downside is that it isn't very easy to code, normally Libraries/Frameworks/luathingys make you put all the arguments in between the start and the argument you want to put in.

qaisjp wrote:Lol I see your point

I don't think you do.

In case you didn't catch my intention, I was trying to say that the behavior of this function is highly varied based on the number of parameters given, and may be too confusing to explain in one go. The existing model in the wiki to break it down into 4 explanations is probably best to prevent confusion.

I think something like:
function( WIKI [, ignorance] )