OOPs in Lua

classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

OOPs in Lua

Muqtheear S
Hi all,
        Please suggest me a Lua OOP library which should support Abstract classes along with some basic feature as well.

Thanks & Regards,
Muqtheear.S
Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Rob Kendrick-2
On Thu, May 16, 2013 at 01:20:51PM +0530, Muqtheear S wrote:
> Hi all,
>         Please suggest me a *Lua OOP library* which should
> support*Abstract classes
> * along with some basic feature as well.

There are plenty of OOP libraries to choose from on the same wiki Steve
suggested to you before, go pick one you like.  If you don't like any of
them, write your own.

Alternatively, if you're trying to turn Lua into some other language
with heavyweight OOP, perhaps you should be using something other than
Lua.

B.

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

steve donovan
On Thu, May 16, 2013 at 10:27 AM, Rob Kendrick <[hidden email]> wrote:
Alternatively, if you're trying to turn Lua into some other language
with heavyweight OOP, perhaps you should be using something other than
Lua.


Yes, with a dynamically-typed language with closures, you don't need all the machinery, and in fact it gets in the way. It _could_ be done (although offhand I don't know an implementation of the concepts of interfaces and abstract classes) but in C++ it's a necessity, whereas  in Lua it's a way of getting better runtime errors, at the cost of making everything unnecessarily rigid and strongly coupled.

An interesting idea which is definitely transportable is Go's idea of _interfaces_; if we have an interface containing a single method like 'write', then _any_ type which implements that method satisfies the interface, even if that type didn't 'implement' that type explicitly. It doesn't work in the case of function overloading, but Go and Lua don't have that problem anyway.

I would recommend that the OP reads as much 'idiomatic' Lua code as possible, to see how experienced programmers use Lua. I do use classes, but have never felt the need for multiple inheritance (which has a runtime cost anyway)


steve d.

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Petite Abeille
In reply to this post by Rob Kendrick-2

On May 16, 2013, at 10:27 AM, Rob Kendrick <[hidden email]> wrote:

> There are plenty of OOP libraries to choose from on the same wiki Steve
> suggested to you before, go pick one you like.  If you don't like any of
> them, write your own.

On that note…  you might want to take a look at Programming in Lua,  Chapter 16 – Object-Oriented Programming:

http://www.lua.org/pil/16.html 






Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Coda Highland
In reply to this post by steve donovan
On Thu, May 16, 2013 at 1:41 AM, steve donovan
<[hidden email]> wrote:
> An interesting idea which is definitely transportable is Go's idea of
> _interfaces_; if we have an interface containing a single method like
> 'write', then _any_ type which implements that method satisfies the
> interface, even if that type didn't 'implement' that type explicitly. It
> doesn't work in the case of function overloading, but Go and Lua don't have
> that problem anyway.

Which is, of course, another way of saying "duck typing".

/s/ Adam

Reply | Threaded
Open this post in threaded view
|

RE: OOPs in Lua

Thijs Schreijer
Most complete OOP library I'm aware of is LOOP[1], which supports simple and more complex (multiple inheritance for example) models.

[1] http://loop.luaforge.net/manual/index.html

Thijs

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Steve Litt
In reply to this post by Rob Kendrick-2
On Thu, 16 May 2013 09:27:31 +0100
Rob Kendrick <[hidden email]> wrote:

> On Thu, May 16, 2013 at 01:20:51PM +0530, Muqtheear S wrote:
> > Hi all,
> >         Please suggest me a *Lua OOP library* which should
> > support*Abstract classes
> > * along with some basic feature as well.
>
> There are plenty of OOP libraries to choose from on the same wiki
> Steve suggested to you before, go pick one you like.  If you don't
> like any of them, write your own.


Rob's not being facetious suggesting writing your own. Creating your
own tools in Lua is much easier than in other languages, thanks to
Lua's simplicity, table-centricity, functions as data (first class) and
nested functions with upvalues.

I'm not a big fan of inheritance, and therefore I'm not knowledgeable
about abstract classes, but my understanding is that if you have the
ability to do inheritance, that pretty much gives you the ability to do
abstract classes. From what I understand from the people on this list,
you do inheritance with metatables. When I make "classes" in Lua, I use
a table with a functional element called "new", that returns a data
table called "self" that contains the "object methods", while the new
function itself contains the "object properties".

The last thing I'd like to say is that Lua is different enough that
sometimes you can use an easier algorithm or architecture with Lua than
with most other languages. For my EMDL to UMENU converter, in Perl,
Python and Ruby I used pretty much standard OOP. But when I wrote the
same program in Lua, Lua's extremely powerful, versatile and efficient
tables gave me a different, and in my opinion easier, way to solve the
problem.

SteveT

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Kevin Clancy
In reply to this post by Muqtheear S
I implemented a class system with abstract methods but not multiple inheritance. Structural subtyping between parent and child classes is enforced by a type checker that I wrote. I'll admit that it's pretty weird; because abstract methods require no function implementation, I  represent them syntactically using empty table constructors, with type annotations included in comments.

The class system is described here: https://bitbucket.org/kevinclancy/basic-class-system/wiki/Home.

Because an abstract class is basically a type definition, and because lua is a dynamic language with no facilities for defining types, I think you're unlikely to find many OOP libraries supporting abstract methods.

Kevin
On 5/16/2013 2:50 AM, Muqtheear S wrote:
Hi all,
        Please suggest me a Lua OOP library which should support Abstract classes along with some basic feature as well.

Thanks & Regards,
Muqtheear.S

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Tim Hill

>
> Because an abstract class is basically a type definition, and because lua is a dynamic language with no facilities for defining types, I think you're unlikely to find many OOP libraries supporting abstract methods.
>

Really? I agree generally with your main points, but I see no barrier to doing type abstraction in Lua if you REALLY need it (which, I feel, you normally don't .. most people who ask for this are, I suspect, doing so because they've been taught to do that in other languages).

The difference in Lua, of course, is that values carry type information, nor variables, so the type system must be dynamic (run time), not static. For example:

type1 = { f1 = "number", f2 = "boolean", f3 = "string" }

There … a type. At this point an "istype(…)" function is pretty easy to write, all you do is check the fields of a table against the types specified by the above table, which is then a template or interface or whatever you want to call it. This is pretty easy to do for variadic functions also (though a bit harder for fixed functions), and thus can also be applied to methods.

Not saying this is elegant, or even good .. I would probably never use it, but it IS possible.

--Tim


Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Rena

On 2013-05-16 7:19 PM, "Tim Hill" <[hidden email]> wrote:
>
>
> >
> > Because an abstract class is basically a type definition, and because lua is a dynamic language with no facilities for defining types, I think you're unlikely to find many OOP libraries supporting abstract methods.
> >
>
> Really? I agree generally with your main points, but I see no barrier to doing type abstraction in Lua if you REALLY need it (which, I feel, you normally don't .. most people who ask for this are, I suspect, doing so because they've been taught to do that in other languages).
>
> The difference in Lua, of course, is that values carry type information, nor variables, so the type system must be dynamic (run time), not static. For example:
>
> type1 = { f1 = "number", f2 = "boolean", f3 = "string" }
>
> There … a type. At this point an "istype(…)" function is pretty easy to write, all you do is check the fields of a table against the types specified by the above table, which is then a template or interface or whatever you want to call it. This is pretty easy to do for variadic functions also (though a bit harder for fixed functions), and thus can also be applied to methods.
>
> Not saying this is elegant, or even good .. I would probably never use it, but it IS possible.
>
> --Tim
>
>

Lately I've been wishing for a simple "interface" functionality in Lua, where I could say "anything implementing 'foo' must have methods x, y and z" and perhaps provide default methods as well. But I haven't been able to come up with a syntax that isn't awkward and doesn't add overhead to every instantiation. For that matter since Lua is interpreted, any kind of interface system would add overhead to at least every time the module is loaded, which might be an issue for e.g. a web server; I wonder if there's a way to eliminate that overhead using luac...

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

steve donovan
On Fri, May 17, 2013 at 1:41 AM, Rena <[hidden email]> wrote:

doesn't add overhead to every instantiation. For that matter since Lua is interpreted, any kind of interface system would add overhead to at least every time the module is loaded, which might be an issue for e.g. a web server; I wonder if there's a way to eliminate that overhead using luac...

One approach is to only do the checking when in 'debug' mode, although Tony Hoare thought that switching off assertions in production was like going to sea without lifeboats. There are caching tricks possible (so that the metatables of objects implementing certain interfaces get flagged as supporting them dynamically) but still it can be expensive.  As for luac, I suspect we've already lost most type information hints at that point.  You'd need a static type inference system and that's not an easy thing, and not always possible without some static type annotations.


Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Dirk Laurie-2
In reply to this post by Rena
2013/5/17 Rena <[hidden email]>:

> Lately I've been wishing for a simple "interface" functionality in Lua,
> where I could say "anything implementing 'foo' must have methods x, y and z"
> and perhaps provide default methods as well. But I haven't been able to come
> up with a syntax that isn't awkward and doesn't add overhead to every
> instantiation. For that matter since Lua is interpreted, any kind of
> interface system would add overhead to at least every time the module is
> loaded, which might be an issue for e.g. a web server; I wonder if there's a
> way to eliminate that overhead using luac...

Overheads are a price you pay when you need the protection and which you
save when you think you don't need it. I prefer to see what security I
am getting and to be aware of the price that I am paying for it, rather
than relying on some invisible ever-present kind.

So I like to see the mechanism, and don't mind expending a function call
on it. There are two mechanisms in Lua itself which I have used from
time to time, often both in one application, one for strict typing and
one for duck typing. They vary from application to application, but are
always something like this:

1. "is".

    function is(typ)
       return function(obj)
          return known[typ] and known[typ](obj)
              or (get(obj,'class') or type(obj)) == typ
       end
    end

    where 'known' is a table of functions that check types, and
    'get' is a generalization of 'rawget' that does not choke if
    called with a non-table.

    Usage for seldom-needed cases:
       is"thread"(obj)
    Usage for common cases:
       is_table = is"table" -- once
       is_table(obj)

2. "has".

   function has(methods)
      return function(obj)
         for method in methods:gmatch"[A-Za-z][A-Za-z0-9]*" do
            if not get(obj,method) then return false end
         end
         return true
      end
   end

   Usage for seldom-needed cases:
      has"assign,clear,new,delete"(obj)
   Usage for common cases:
      has"table"=has"concat,insert,remove,pack,unpack,sort" -- once
      has_table(obj)

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

steve donovan
On Fri, May 17, 2013 at 9:26 AM, Dirk Laurie <[hidden email]> wrote:
   Usage for seldom-needed cases:
      has"assign,clear,new,delete"(obj)
   Usage for common cases:
      has"table"=has"concat,insert,remove,pack,unpack,sort" -- once
      has_table(obj)


Nice notation - I'm assuming that 'has"table"' should be 'has_table' in the assignment. Easy enough to optimize by making a set out of the methods.

Reply | Threaded
Open this post in threaded view
|

Re: OOPs in Lua

Dimiter 'malkia' Stanev
In reply to this post by steve donovan
> One approach is to only do the checking when in 'debug' mode, although
> Tony Hoare thought that switching off assertions in production was like
> going to sea without lifeboats.

Often in the game industry we go in the deep sea even without a ship :)