[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Need standard kernel supported class in Lua, was: Macros and expressivity
- From: Javier Guerra Giraldez <javier@...>
- Date: Mon, 14 Jan 2008 21:03:41 -0500
On Monday 14 January 2008, Eric Tetz wrote:
> On Jan 14, 2008 2:39 PM, Jerome Vuarand <firstname.lastname@example.org> 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
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
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?
Description: This is a digitally signed message part.