lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

On Monday 14 January 2008, Eric Tetz wrote:
> On Jan 14, 2008 2:39 PM, Jerome Vuarand <> wrote:
> > Just use the simplest one until you feel you need more features.
> But if Jane writes class X using one model, Joe can't derive class Y
> from it using a different model, right? So this does nothing to
> ameliorate the problem I was talking about. Doing any OO programming
> in Lua represents a commitment to a specific scheme, or the acceptance
> that you will have N incompatible object representations in your code.

great, this is a specific problem (or perceived problem); so let's analyse it 
specifically :-)

first my favourite point: inheritance is _very_ seldom the best answer.

why is inheritance so common? i believe it's because static-typed languages 
need some assurance about 'minimum commonality' between two similar objects.  
that is, if bot A and B inherit from C, wherever you can use C, you can use 
either A or B; but it would be treated like C, except for run-time 
polymorphic differences.

in fully dynamic languages, where there's no compile-time type checking, 
there's no need to assure any pre-set commonality structure between similar 
objects.  a given function can receive any kind of object, as long as it 
implements this and that methods.

i (personally) think this is a great advantage, when using C++ or Java i spend 
most of the design time deciding which class should inherit from which.  in 
dynamic languages, i simply choose a few objects 'classes' and make them as 
similar as possible. any method that operates on more than one without any 
change, can simply be shared.

in short: inheritance is on most cases not a feature, just a simplistic method 
for expressing similarity.

second point:  "you will have N incompatible object representations in your 

most Lua OOP systems are light and simple.  usually little more than handy 
functions to assign metatables.  usually no big deal porting a small library 
from one to another... most are the same thing under the hood.

third point: if you use inheritance, you've already chosen one.

so, sometimes inheritance _does_ help, and maybe help a LOT.  what's the most 
common case? well, frameworks, of course!  especially GUI frameworks, where 
there are lots of very similar objects.  it just makes sense to arrange most 
of them in a neat hierarchy.

hum... how many frameworks can coexist in a given program?  if you want more 
than one, i think OOP libraries are not the biggest challenge.

so, you have a big framework, with nice classes implemented in model such and 
such.  now you want to write your own class.  if it inherits from a 
framework's class, just use that method.  what's the problem?

and what about the framework writer?

well, he's writing a foundation library, it's natural that he'd make the 
choice of tools, including the OOP library, if he wants one.

the only special consideration i see is if he wants to use somebody else's 
library for some specific part, and it uses a different OOP model.

well, no problem at all! just use it!

most Lua libraries available are well-contained modules. those that uses 
OOP-like objects simply define a few metatables.  there's nothing to prevent 
somebody using LOOP to use LuaSocket.  even if the LuaSocket model isn't the 
simplest one, it doesn't get in the way.

or does it?


Attachment: signature.asc
Description: This is a digitally signed message part.