Re: How can I learn about Object Oriented programming with lua?

["Journeyer J. Joh" <oosaprogrammer@...>]

Hi Javier Guerra Giraldez,

I agree that GoF patterns are not 100% useful in Lua.

When I study GoF in C++, GoF patterns were not the best SW design in C++ either.

For Bridge pattern, GoF's Bridge pattern is not the best in C++. I found a generic template based bridge pattern from the book - C++ Template the complete guide : David Vandevoorde. This means even C++ GoF's patterns are not the best.

Nowadays for C++, generic programming is another design choice.

Like C++, I believe Lua would be same. Some patterns would be good with Lua but some patterns would be too much in Lua. For the State pattern, PIL mentions tail call function approach.

Implementing GoF is only a means for me to study OO style programming in Lua.

By this study, I'd like to find better design in Lua. Like I found generic Bridge pattern for C++.

Sincerely

Journeyer

----------------------------------------
Journeyer J. Joh
o o s a p r o g r a m m e r
a t
g m a i l  d o t  c o m
----------------------------------------

2014-02-24 23:02 GMT+09:00 Javier Guerra Giraldez <javier@guerrag.com>:

On Mon, Feb 24, 2014 at 12:20 AM, Journeyer J. Joh
<oosaprogrammer@gmail.com> wrote:
> There is an easy but very good book about GoF, I've read this book more than
> 2 times and created an documentation project - the one above. The book is
> using Java. My project above uses C++ and UML. Now I am about to create one
> for lua.

keep in mind that the GoF book is very much about class-based
static-typing OOP (mostly Java and C++).  there are patterns that
might not be a good idea in dynamic languages (façades? duck-typed
proxies are easier and lighter in most cases), or some things that
have to be explicitly taught in those languages but are unneeded in
others (i.e. functors... we have closures!)


there's also the extreme view that "a design pattern is a symptom of
missing features", with the revealing tale about how in very old
times, it was considered good practice to push the current program
counter into some stack before jumping to some other code, and at the
end it would just pop that address instead of trying to jump back to
some hardcoded landing point.... and how later on, some people started
putting some information about how to perform an action on that same
stack!... even later, some small pieces of code even considered the
case where it could be running twice, one inside another, so had the
great idea to put temporary storage in the same stack again...  now
all this is part of any language design, but at the time, it could've
been called a design pattern.


in the specific case of Lua, I think that there's nothing wrong with
class-based OOP, but in my experience, it's very seldom useful.  in
most of my programs, you can see small objects with well-defined
encapsulation, and in many cases there's polymorphism too; but so far
haven't needed any inheritance.  much less any hierarchy-based
dispatching.  and, of course, without using any OOP "implementation",
since setting the right metatables is just at most one extra line in
the object constructor.


in short, i'm very skeptical of any effort to just "lets implement GoF
in Lua!".  much better would be something like "lets redo those
designs in Lua!", noting that many of those would be very different
than what's on the book.  extra points (in my eyes) if you get it
without any "OOP layer"


--
Javier