Question

I’m working with Lua and C++ (using LuaWrapper) and I’m having trouble with something. Let’s say I have these classes:

class Bar{...};
class Foo
{
    ...
    std::map<std::string,Bar*> _barlist;
    ...
    Bar* getBar(std::string key)
    {
        return _barlist[key];
    }
}

class BarDerived1 : public Bar{...}
class BarDerived2 : public Bar{...}

I have access to Foo and Foo::getBar() from Lua , the thing is that the type from the object returned is Bar and I don’t have access to its BarDerivedX methods.

As I understand it, Objects/Classes in Lua are simply MetaTables with functions assigned to keys, so I was wondering if there’s a way to copy these extra functions from the BarDerivedX class to the Bar object (and would that even work?), also, is this the best way to do it or should I cast it in C++ before letting Lua access it?

Answer 1

The purpose of polymorphism, in any language, is to not have to care exactly what type something is. If you give someone, whether Lua or C++, a Bar object, then Bar should have the interfaces that the people need to do whatever they need to do.

That’s the purpose of virtual functions. A virtual function defined in Bar can be overridden with a different behavior in BarDerived1. Other code doesn’t have to know that they are being handed a derived class; they can just take a Bar like always.

There are generally only two reasons to make a class derived from another. The first is polymorphism: you want to specialize a class by altering the behavior of certain functions.

The other reason is to gain access to its implementation. For example, if you’re making a Unicode string, you could use a std::basic_string to store the encoded data. You could then privately derive from std::basic_string, thus allowing you to gain the storage optimizations that std::basic_string has, but you provide a different interface (since private inheritance doesn’t allow the outside world to know that you derived from it).

If you want everyone to use Bar objects that can have different behaviors based on derived classes, then you should be using virtual functions and polymorphism. However, if you are changing the interface in derived classes, then that’s probably a sign of a design problem. Maybe those derived classes shouldn’t be derived classes at all. Maybe they should be entirely separate classes that a Bar instance may or may not have, based on some initialization parameters.

It’s hard to say more without specifics on what you’re actually doing. But in general, if you’re using inheritance-based polymorphism correctly, you shouldn’t need to cast from a Bar to more derived versions. Just use the Bar interface.