c++ semantics dictate that it's accessed by index, but the tests seem to want to indicate that it should be accessed like a hashmap (or just using basic lua table semantics)
i have no idea how to make this incompatibility work in the new system...
i will ask repo master if he knows anything
get turned into getter<T>, matches pusher<T> and uses same semantics as std::allocator and other things used throughout the codebase
-----
userdata has its traits defined outside in new file of userdata to prevent errors when trying to use those typetraits in places before userdata.hpp gets included
userdata was changed to support returning itself via pointers or references.
rework of stack changes semantics based on T&, T*, and T&& (the last one tries to create a new userdata and move in data)
solves problems maybe presented in https://github.com/Rapptz/sol/issues/25
-----
container.hpp is attempt at solving original problem before going on wild tangent with userdata, stack, and get
is going to attempt to use userdata to allow transporation of containers losslessly, perhaps without copying need
-----
found out trying to return a std::function does not work -- not sure what do exactly?
perhaps should push c closure as last thing, but right now it is tied to a key value (code comes from table.hpp and set_function)
will just have to think over how stack arranges itself and learn what to do
tests added to confirm userdata can be passed into C++ function types
demangle is now named lua_demangle, and the core demangle without any replacements (to fit lua) is just named demangle
Formattings fixes everywhere
Fix for userdata to accept base classes where the derived class uses the name of a base member function to access it (Derived::get_num, where get_num is only implemented in Base::get_num)
VC++ makes this acceptance easy by taking the name as "Derived", but GCC and Clang
Refactoring on function_types.hpp performed to slim down some of the calls: could use more refactoring
Drastically simplified userdata's binding capabilities: constructor supports both `:` and `.` syntax (but member functions DO NOT).
All tests are passing
It's going to take serious work to make it happen in GCC, plus the fact that 4.9 is still giving me
so many errors I can't even read it...
I'll let Rapptz figure it out, but later.
Sexy class bindings, yes!
