update examples and documentation

docs/source/safety.rst

@@ -1,7 +1,7 @@
 config and safety
 =================
 
-Sol was designed to be correct and fast, and in the pursuit of both uses the regular ``lua_to{x}`` functions of Lua rather than the checking versions (``lua_check{X}``) functions. The API defaults to paranoidly-safe alternatives if you have a ``#define SOL_CHECK_ARGUMENTS`` before you include Sol, or if you pass the ``SOL_CHECK_ARGUMENTS`` define on the build command for your build system. By default, it is off and remains off unless you define this, even in debug mode. The same goes for ``#define SOL_SAFE_USERTYPE``.
+Sol was designed to be correct and fast, and in the pursuit of both uses the regular ``lua_to{x}`` functions of Lua rather than the checking versions (``lua_check{X}``) functions. The API defaults to paranoidly-safe alternatives if you have a ``#define SOL_CHECK_ARGUMENTS`` before you include Sol, or if you pass the ``SOL_CHECK_ARGUMENTS`` define on the build command for your build system. By default, it is off and remains off unless you define this, even in debug mode.
 
 .. _config:
 
@@ -22,7 +22,7 @@ Note that you can obtain safety with regards to functions you bind by using the
 
 ``SOL_SAFE_USERTYPE`` triggers the following change:
 	* If the userdata to a usertype function is nil, will trigger an error instead of letting things go through and letting the system segfault/crash
-	* Turned on by default with clang++, g++ and VC++ if a basic check for building in debug mode is detected
+	* Turned on by default with clang++, g++ and VC++ if a basic check for building in debug mode is detected (lack of ``_NDEBUG`` or similar compiler-specific checks)
 
 ``SOL_SAFE_FUNCTION`` triggers the following change:
 	* All uses of ``sol::function`` and ``sol::stack_function`` will default to ``sol::protected_function`` and ``sol::stack_protected_function``, respectively, rather than ``sol::unsafe_function`` and ``sol::stack_unsafe_function``.

docs/source/tutorial/all-the-things.rst

@@ -629,9 +629,15 @@ You can emulate namespacing by having a table and giving it the namespace names
 		"g", &my_class::g
 	); // the usual
 
+	// can add functions, as well (just like the global table)
+	bark.set_function("print_my_class", [](my_class& self) { std::cout << "my_class { b: " << self.b << " }" << std::endl; });
+
 	// 'bark' namespace
 	lua.script("obj = bark.my_class.new()" );
 	lua.script("obj:g()");
+	// access the function on the 'namespace'
+	lua.script("bark.print_my_class(obj)");
+
 	my_class& obj = lua["obj"];
 	// obj.b == 25
 

examples/namespacing.cpp

@@ -1,9 +1,12 @@
 #define SOL_CHECK_ARGUMENTS 1
 #include <sol.hpp>
 
+#include <iostream>
 #include <cassert>
 
 int main() {
+	std::cout << "=== namespacing example ===" << std::endl;
+
 	struct my_class {
 		int b = 24;
 
@@ -19,16 +22,26 @@ int main() {
 	sol::state lua;
 	lua.open_libraries();
 
+	// "bark" namespacing in Lua
+	// namespacing is just putting things in a table
 	sol::table bark = lua.create_named_table("bark");
 	bark.new_usertype<my_class>("my_class",
 		"f", &my_class::f,
-		"g", &my_class::g
+		"g", &my_class::g); // the usual
-		); // the usual
 
-	lua.script("obj = bark.my_class.new()"); // this works
+	// can add functions, as well (just like the global table)
+	bark.set_function("print_my_class", [](my_class& self) { std::cout << "my_class { b: " << self.b << " }" << std::endl; });
+
+	// this works
+	lua.script("obj = bark.my_class.new()");
 	lua.script("obj:g()");
+
+	// calling this function also works
+	lua.script("bark.print_my_class(obj)");
 	my_class& obj = lua["obj"];
 	assert(obj.b == 25);
 
+	std::cout << std::endl;
+
 	return 0;
 }