Re: Need standard kernel supported class in Lua, was: Macros and expressivity

[Javier Guerra Giraldez <javier@...>]

On Monday 14 January 2008, Eric Tetz wrote:
> On Jan 14, 2008 2:39 PM, Jerome Vuarand <jerome.vuarand@ubisoft.com> 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 
code"

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?

-- 
Javier

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