lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Hi Javier Guerra Giraldez,

I must say I am sorry. I didn't intent to make you write this much writings to me.
And I understand what you and Steve and Sean trying to say now.

So far I tried not to face a need to learn functional programming. This is because I am afraid of it. OO took me long time to master(?). I didn't want any other take me and my time any more. ^^;

But I think I finally faced it. In front of me it is.

(I assumed dynamic language(lua) requires functional programming above.)

Thank you for your kindness.


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-26 23:47 GMT+09:00 Javier Guerra Giraldez <>:
On Wed, Feb 26, 2014 at 9:11 AM, Journeyer J. Joh
<> wrote:
> I wonder if Steve and Javier think that I am doing useless study now.
> I believe OO style is nothing wrong then, what am I doing wrong now?

not useless or wrong, it's just a new world :-)

it seems you're experienced mostly in static class-based languages,
and that's what the GoF book is about.  but dynamic languages are
different, not just 'smaller'.  in fact, a big part of OOP could be
seen as a small approximation to dynamic-like features.  Late binding,
polymorphism, custom typing... all this is 'natural' in dynamic

It's a rite of passage here in the Lua list.  almost all of us started
enthusiastically creating a new OOP library.  you're original in that
instead of that you chose an existing library and proceeded to
implement the GoF patterns.  :-)

I'm not sure that i've said it already in this thread, but I consider
that OOP is about encapsulation and polymorphism.  inheritance isn't
needed; it's widely used mostly because it's the easiest way to match
polymorphism with a static type system.

consider this:

1.- I have encapsulation, so i can define both state and behavior in a
single value. now, how can i handle several values together?

2A: (static type): hum... lets define a new type. we can call it a 'class'

2B: (dynamic type): no prob, just do it.  if you want to create them
similarly, we can define some template... let's call it a 'prototype'.

3.- sweet, now, i want some values to have slightly different behavior

4A.- (static type): ok, make those a different type, or rather, a new class

4B.- (dynamic type): no prob, just do it.  oh, if you want to do it
repeatedly you can (if you wish) define a new prototype

5.- great, now I want to call the respective (different) behavior with
this single function

6A.- (static type): wowowow, but these are different types, which type
are you going to declare your variables??  hum... well, lets define
that this and this classes have some things in common... make them
'inherit' from a superclass and use that to declare the variables....
umpf, i'll have to attach a runtime table to pick the respective
behavior... but at least the compiler will have something to do all
the static checks.

6B.- (dynamic type): no prob, just declare the respective methods with
the same name, and (roughly) equivalent parameters.

well, i guess that's what i'm trying to say, how some well entrenched
concepts, that are mostly taught as "defining characteristics or OOP"
might in fact be just reasonable solutions for specific languages.
here i've taken on inheritance, but virtual/nonvirtual, or RAII, or
most of GoF patterns can be just as language-specific....