Abstract classes and interfaces in Lua

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

Abstract classes and interfaces in Lua

luciano de souza-2
Hello all,
Dispite of the fact Lua is not a object oriented language, by means of
modules like Penlight, we have support.
However, some design patterns like Strategy, Abstract Factory or
Visitor demands, as far as I able to know, abstract classes or
interfaces.
So my question is: is there Lua implementations for abstract classes
or interfaces?
More broadly, I ask: does someone know examples of design pattern
implementation in Lua?
Best regards,

--
Luciano de Souza

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

Andrew Starks-2
I've never been able to reason about the value or utility of most patterns, within the context of Lua, which is a dynamic language.

For example: my understanding is that interfaces are a way to say that a particular object has all of the methods and properties that are defined by an interface. In a dynamic language, you can simply say that it does (if obj.interfaces.foo then) and then support those methods---if you don't it won't work so you need to test.

Building up checks for compliance on a language level is probably possible (to some degree less than 100%), but it doesn't jive with Lua, in my experience. In order to enforce enough limitations to make such a concept useful, you have to build up type checking, etc. Eventually there is a point where the complexity and performance trade offs lead me to understand why such a thing didn't exist in the first place.

That is, whenever I found myself meta-programming in Lua, I end up throwing it away.

My .02 cents. I suspect that you won't find this helpful, but I've tried to implement interfaces before and your question reminded me of that experience.

-Andrew
On Fri, Apr 14, 2017 at 10:22 luciano de souza <[hidden email]> wrote:
Hello all,
Dispite of the fact Lua is not a object oriented language, by means of
modules like Penlight, we have support.
However, some design patterns like Strategy, Abstract Factory or
Visitor demands, as far as I able to know, abstract classes or
interfaces.
So my question is: is there Lua implementations for abstract classes
or interfaces?
More broadly, I ask: does someone know examples of design pattern
implementation in Lua?
Best regards,

--
Luciano de Souza

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

steve donovan
On Fri, Apr 14, 2017 at 6:50 PM, Andrew Starks <[hidden email]> wrote:
> That is, whenever I found myself meta-programming in Lua, I end up throwing
> it away.

I've come to think that myself ;)

Interfaces should obviously be documented, but they don't really make
sense for dynamic languages. But you do _test_ against interfaces.

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

luciano de souza-2
In reply to this post by Andrew Starks-2
Andrew,
If interfaces doesn't make sense in Lua, so I really can follow another way.
Actually, I feel myself a little bit lost. In other languages, we can
find many references talking about OOP, abstract classes, interfaces,
dependence injection...
With the GOF design patterns, we can assimilate several conceptual
structures and apply it.
The problem is that Lua is so different that I am not able to
understand whats the best practices.
Does we have example of design patterns in Lua? Does GOF patterns make
sense in Lua?
The reason I am using Penlight as an OOP module, even though the
metaprograming features, indicates that I am not confortable with this
lack of references.
Penlight is a very good library and allows me to think as I thought
before Lua. In the future, perhaps my mind changes, but the truth is
that Penlight allows me not to change everything.
Using Penlight, I can implement Visitor, Strategy, Abstract Factory...
If this is not natural for LUa, what's is natural? How can I find
models to follow?

2017-04-14 13:50 GMT-03:00, Andrew Starks <[hidden email]>:

> I've never been able to reason about the value or utility of most patterns,
> within the context of Lua, which is a dynamic language.
>
> For example: my understanding is that interfaces are a way to say that a
> particular object has all of the methods and properties that are defined by
> an interface. In a dynamic language, you can simply say that it does (if
> obj.interfaces.foo then) and then support those methods---if you don't it
> won't work so you need to test.
>
> Building up checks for compliance on a language level is probably possible
> (to some degree less than 100%), but it doesn't jive with Lua, in my
> experience. In order to enforce enough limitations to make such a concept
> useful, you have to build up type checking, etc. Eventually there is a
> point where the complexity and performance trade offs lead me to understand
> why such a thing didn't exist in the first place.
>
> That is, whenever I found myself meta-programming in Lua, I end up throwing
> it away.
>
> My .02 cents. I suspect that you won't find this helpful, but I've tried to
> implement interfaces before and your question reminded me of that
> experience.
>
> -Andrew
> On Fri, Apr 14, 2017 at 10:22 luciano de souza <[hidden email]> wrote:
>
>> Hello all,
>> Dispite of the fact Lua is not a object oriented language, by means of
>> modules like Penlight, we have support.
>> However, some design patterns like Strategy, Abstract Factory or
>> Visitor demands, as far as I able to know, abstract classes or
>> interfaces.
>> So my question is: is there Lua implementations for abstract classes
>> or interfaces?
>> More broadly, I ask: does someone know examples of design pattern
>> implementation in Lua?
>> Best regards,
>>
>> --
>> Luciano de Souza
>>
>>
>


--
Luciano de Souza

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

steve donovan
On Fri, Apr 14, 2017 at 7:34 PM, luciano de souza <[hidden email]> wrote:
> With the GOF design patterns, we can assimilate several conceptual
> structures and apply it.
> The problem is that Lua is so different that I am not able to
> understand whats the best practices.

Those patterns still work, except for the ones explicit talking about
statically-typed languages like Java or C++ (Interfaces, Abstract Base
classes, etc).

Lua isn't very different. Like Javascript, it doesn't have a built-in
class system [1], but in a few lines we can create one. (I'm glad that
people like the one in Penlight, which I tried to keep as simple as
possible. Sometimes people ask me to make it do all kinds of strange
things)

Most of the GoF patterns are still applicable.

[1] been playing with Rust, and man does that mess with people's
heads. It doesn't do standard OOP either (it's more Go-ish) and people
get so anxious that they don't have a 'class' keyword and
implementation inheritance and all those other things people learn at
school

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

Sean Conner
In reply to this post by luciano de souza-2
It was thus said that the Great luciano de souza once stated:
>
> The problem is that Lua is so different that I am not able to
> understand whats the best practices.
> Does we have example of design patterns in Lua? Does GOF patterns make
> sense in Lua?

  There's a school of thought that says that design patterns are a sign of
weakness in a language (I follow that school myself [1]).  From the
Wikipedia article on Design Patterns [2]:

        Significant criticism has been directed at the concept of software
        design patterns generally, and at Design Patterns specifically.

        A primary criticism of Design Patterns is that its patterns are
        simply workarounds for missing features in C++, replacing elegant
        abstract features with lengthy concrete patterns, essentially
        becoming a "human compiler" or "generating by hand the expansions of
        some macro".[4] Peter Norvig demonstrates that 16 out of the 23
        patterns in Design Patterns are simplified or eliminated (via direct
        language support) in Lisp or Dylan.[5] Related observations were
        made by Hannemann and Kiczales who implemented several of the 23
        design patterns using an aspect-oriented programming language
        (AspectJ) and showed that code-level dependencies were removed from
        the implementations of 17 of the 23 design patterns and that
        aspect-oriented programming could simplify the implementations of
        design patterns.[6]

        Paul Graham wrote:[4]

                When I see patterns in my programs, I consider it a sign of
                trouble. The shape of a program should reflect only the
                problem it needs to solve. Any other regularity in the code
                is a sign, to me at least, that I'm using abstractions that
                aren't powerful enough-- often that I'm generating by hand
                the expansions of some macro that I need to write.

  It's commendable that you want to follow the best practices for Lua, but
also remember, the map is not the territory.

  -spc (Just tossing this out there ... )

[1] I've used design patterns before.  One I used quite a bit was
        "Register Passing of Parameters" and it worked like this:

                Non-pointer parameters are passed in AX or DX

                A non-pointer parameter used as a counter passed in CX

                Pointers to source data passed in SI or BX

                Pointers to data destinations passed in DI

        You might not think that is a "design pattern" but it follows from
        the GOF book---it is a programming pattern.  But such a pattern
        doesn't make sense once you start using something other than
        Assembly.

[2] https://en.wikipedia.org/wiki/Design_Patterns#Criticism

[3] This footnote intentionally left blank

[4] Wikipedia reference

[5] Wikipedia reference

[6] Wikipedia reference

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

Andrew Starks-2
In reply to this post by luciano de souza-2

On Fri, Apr 14, 2017 at 12:34 luciano de souza <[hidden email]> wrote:
Andrew,
If interfaces doesn't make sense in Lua, so I really can follow another way.
Actually, I feel myself a little bit lost. In other languages, we can
find many references talking about OOP, abstract classes, interfaces,
dependence injection...
With the GOF design patterns, we can assimilate several conceptual
structures and apply it.
The problem is that Lua is so different that I am not able to
understand whats the best practices.
Does we have example of design patterns in Lua? Does GOF patterns make
sense in Lua?
The reason I am using Penlight as an OOP module, even though the
metaprograming features, indicates that I am not confortable with this
lack of references.
Penlight is a very good library and allows me to think as I thought
before Lua. In the future, perhaps my mind changes, but the truth is
that Penlight allows me not to change everything.
Using Penlight, I can implement Visitor, Strategy, Abstract Factory...
If this is not natural for LUa, what's is natural? How can I find
models to follow?

TL;DR

I don't know that I can answer the question in the way that you might want or expect, but my answer is that Lua is very different, as you say. It's extremely simple and does not favor one style of programming over another, accepting small nods like the colon operator. 

Once I was talking to a C# programmer about some problem I was trying to solve; I think I was trying to implement some aspect of OOP that was very basic. 

I'm not a programmer by education and he is. It took him a while to understand what I was asking because "good object oriented design" had been drilled into him from day one and from every direction: his professors, the books he read, his coworkers and the language he was using. It had not occurred to him that there was another way to program, although of course he knew that there was. The lazy model that he admitted to having was some sort of hierarchy like: first came spaghetti  code, then procedures, then OOP fixed everything.

It's hard to unlearn the behaviors that the languages you're using expect from you. If you want to make programs in Lua, it's better to think in Lua than it is to try to foist concepts from other languages into it. 

Another example came from working with a long time systems level C++ programmer who was helping with the Lua C API. He was fighting with Lua tooth and nail. One day I tried to test for the existence of a field on userdata that I had gotten from him. Whenever I indexed a nil value, the program would fail an ASSERT and crash out. He had manually trapped any attempts to access nonexistent values. He did this because the Lua C API hadn't done it for him and in his mind, he was covering his bases. I had to spend some serious energy and time to explain to him why the ability to attempt to access a nonexistent table/userdata value was a useful feature and not lazy, bad practice. 

So, I guess I'm saying that I recognize your concern as something that Is similar to past experiences and that your disorientation is not unique and will not be as well served by bolting features on to Lua as it would be by learning more about how problems can be solved (and scaled) with what is there and how what is there is composed. In the end, I think that you will find that Lua will greatly enhance your perspective and you will want to solve many problems with it, in the future. 




2017-04-14 13:50 GMT-03:00, Andrew Starks <[hidden email]>:
> I've never been able to reason about the value or utility of most patterns,
> within the context of Lua, which is a dynamic language.
>
> For example: my understanding is that interfaces are a way to say that a
> particular object has all of the methods and properties that are defined by
> an interface. In a dynamic language, you can simply say that it does (if
> obj.interfaces.foo then) and then support those methods---if you don't it
> won't work so you need to test.
>
> Building up checks for compliance on a language level is probably possible
> (to some degree less than 100%), but it doesn't jive with Lua, in my
> experience. In order to enforce enough limitations to make such a concept
> useful, you have to build up type checking, etc. Eventually there is a
> point where the complexity and performance trade offs lead me to understand
> why such a thing didn't exist in the first place.
>
> That is, whenever I found myself meta-programming in Lua, I end up throwing
> it away.
>
> My .02 cents. I suspect that you won't find this helpful, but I've tried to
> implement interfaces before and your question reminded me of that
> experience.
>
> -Andrew
> On Fri, Apr 14, 2017 at 10:22 luciano de souza <[hidden email]> wrote:
>
>> Hello all,
>> Dispite of the fact Lua is not a object oriented language, by means of
>> modules like Penlight, we have support.
>> However, some design patterns like Strategy, Abstract Factory or
>> Visitor demands, as far as I able to know, abstract classes or
>> interfaces.
>> So my question is: is there Lua implementations for abstract classes
>> or interfaces?
>> More broadly, I ask: does someone know examples of design pattern
>> implementation in Lua?
>> Best regards,
>>
>> --
>> Luciano de Souza
>>
>>
>


--
Luciano de Souza

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

steve donovan
On Sat, Apr 15, 2017 at 12:52 AM, Andrew Starks <[hidden email]> wrote:
> knew that there was. The lazy model that he admitted to having was some sort
> of hierarchy like: first came spaghetti  code, then procedures, then OOP
> fixed everything.

Heh, leading to the so-called Lasagna model of programming - layers
all the way down. It's still Pasta.

This is all excellent advice - look at the structure of the problem,
and find whatever abstractions that needs to make that structure
appear in the solution. That is, abstraction is the handmaiden of
functionality.  This is difficult advice, if you want a handbook of
pre-solved solutions. Education can sometimes be harmful (as Andrew's
C# programmer shows) and gets in the way of thinking creatively.  I do
use OOP for big jobs but rarely use inheritance - because that's a
solution to a static-typing problem (if Cat is-a Animal, then Cats may
be passed to an interface expecting Animals). I don't need subtyping
or implementation inheritance (my classes may just use private
functions to keep common functionality).  And here is something: I've
found myself using closures more and more, where a traditional OOP
model would need a class for implementation. And abstract or pure
implementation classes would be a good example of patterns that aren't
essential to the problem, they are an artifact of a programming model.

Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

Jorge Visca
On 15/04/17 09:34, steve donovan wrote:
> And here is something: I've
> found myself using closures more and more, where a traditional OOP
> model would need a class for implementation.

Closures in Lua have a strange property: they sort of do the right thing
without you having to do explicit design work as in Java or C++. You
just have to think about the scope of your variables: what declaration
is visible from where, and if you get that right, everything will just
work. And the scoping in Lua is very simple.



Reply | Threaded
Open this post in threaded view
|

Re: Abstract classes and interfaces in Lua

steve donovan
On Mon, Apr 17, 2017 at 10:56 PM, Jorge <[hidden email]> wrote:
> have to think about the scope of your variables: what declaration is visible
> from where, and if you get that right, everything will just work. And the
> scoping in Lua is very simple.

This is very true, certainly compared to Python or Javascript (my
usual Javascript experience is "WTF is this?").

I did not automatically fall in love with closures, had to get to know
them first. We forget our first pains and remember the romance.