Added assertions, fixed readme and lowercase mod

[Tieske]

The assertions/modifiers that are Lua keywords require at least 1 capital, otherwise Lua will not compile a testfile.

Now working for example;

    assert.is.Not.True(false)

[ajacksified]

I'm torn on this; I think it's a valid change, but I'm also worried about offering too many ways to do the same thing, especially if it deviates from normal (since you have to use capitals, where everywhere else, you don't.) Is there a way to hook into a metatable somewhere to override what not does, or is this a special case for the interpreter?

cc @DorianGray

[DorianGray]

There isn't a way to override what not does and I also hate having capitals in this case. When I built the assertions, I ran up against this exact dillema. Hence is_not

[Tieske]

for the types its straightforward to have this 'natural language' assertion, except for nil, which is a reserved word, just as true/false/not. I agree it isn't pretty, but its the best workaround available. Most of all, once written, it reads very easy, despite the capitals.

I simply prefer

assert.is.Not.True(false)

over

assert.is_not.same(true, false)

[ajacksified]

It's a workaround, and it does read easy, but it also diverts from what we've done elsewhere. I'm up for adding new things, when it fits with the other patterns we've implemented; I feel like this diverges, and having the existing is/is_not fits better. We can do the same thing by providing is_true and is_false and is_nil and keep the same type of language we've been using.

[Tieske]

that would also imply is_not_true, is_not_false and is_not_nil

or you can have both...

[Tieske]

just a thought that came up; would it be better to put them in a separate file (eg. 'typeassertions.lua'), not initially loaded, only when explicitly requested; require("luassert.typeassertions")

[ajacksified]

Yeah... hmm. Curse you, Lua interpreter - you tease me with so much flexibility, and then do this to me ;_;

I'm not sure what the right solution is. I lean towards is_not_true / is_true rather than True, but both seem like a hack, and then you would have to do things like is_not.is_true to get "not true" to work. Which is weird.

re: separate file - I think it's fine to keep it all in assertions for now.

[Tieske]

your call...

[nilnor]

For what it's worth, I would prefer not having to use mixed case. It would be an eye sore, and not blend in well with how the specs reads otherwise. So if there's a way of addressing this using is_nil et al then for the love of everything that is holy please do that :)

[Tieske]

funny thing that casing stuff, I never got all those strong opinions floating around it. I'll put it in a separate library, which then can be used on top of luassert.

[ajacksified]

For me, it's not about the casing as much as maintaining consistency.

I think we should move forward with is_true and variants.

[nilnor]

Right. I should clarify that when I said mixed case I wasn't referring to mixed case for variables or functions themselves, but rather the mix of some asserts being lower case and some being capitalised.

[Tieske]

Just put in some more Lua flexibility... it now automagically handles the underscore chaining. So assert.is_not_true(bla) is handled, just as assert.is.not.True(bla), without having to add/register new modifiers. Additional benefit is that 'is_not', 'are_not', etc. have been removed as modifiers, as they will automatically be handled based on the underscore chaining.

So its up to the user, whether his coding style prefers underscores or capitals.