Re: Need standard kernel supported class in Lua, was: Macros and expressivity (original) (raw)

lua-users home

[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 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.