prototype modeling as an alternative to OOP

[EmmanuelOga]

Hi,

I see from time to time in these forums posts about OOP implementations for lua. I wanted to share this article which I found very interesting in this regard:

http://steve-yegge.blogspot.com/2008/10 ... ttern.html

In the article the author explains prototypical modeling as an alternative to OOP and how he implemented the pattern in a language which has not support for it (namely java). While he is at it, he explains many of the advantages of the pattern and gives examples of how to use it.

One thing I found remarkable is that the author goes to great lengths to implement something we have for free with lua .

Hope you'll find it interesting.

[genericdave]

I'm so lost. I agree that lua is pretty sweet, however.

[kikito]

I already knew about that article, and I'm afraid I didn't like it very much.

IMHO it is way too verbose. The idea he tries do lay down could be written in two or three paragraphs and some example code. Most of the contextual information he does is unnecesary; people with OOP knowledge will already know it and people without it will not be interested in that kind of article anyway. The implementation details would be better off in other posts.

[BlackBulletIV]

I agree with verbose, I certainly didn't read it because of the sheer size. You could almost turn it into a mini-book!

But I think I get the prototype concept, purely from the fact that I saw he mentioned that JavaScript had this at its core.

[EmmanuelOga]

I agree it is more verbose than it could. I guess it could be trimmed easily at least 50%, and then with a little more work another 25% . If you absolutely can't stand read it, then just look at this short quote:

Imagine you're listening to announcers commenting on an NFL (American football) game. They're talking about a new rookie player that you don't know anything about. At this point, the rookie – let's say his name is L.T. – is just an instance of the class "football player" with no differentiation.

The announcers mention that L.T. is a running back: a bit like Emmitt Smith in that he has great speed and balance, and he's great at finding holes in the defense.

At this point, L.T. is basically an "instance" of (or a clone of) Emmitt Smith: he just inherited all of Emmitt's properties, at least the ones that you're familiar with.

Then the announcers add that L.T. is also great at catching the ball, so he's sometimes used as a wide receiver. Oh, and he wears a visor. And he runs like Walter Payton. And so on.

As the announcers add distinguishing attributes, L.T. the Rookie gradually takes shape as a particular entity that relies less and less on the parent class of "football player". He's become a very, very specific football player.

But here's the rub: even though he's a specific instance, you can now use him as a class! If Joe the Rookie comes along next season, the announcers might say: "Joe's a lot like L.T.", and just like that, Joe has inherited all of L.T.'s properties, each of which can be overridden to turn Joe into his own specific, unique instance of a football player.

I found that quote (and what follows next) useful to start thinking on how to model things with prototypes (btw, I admit I'm still long away from being proficient in such modeling ).

After working with both OOP in gral and with javascript specifically, I realized I was all the time trying to cram OOP in every language I was getting my hands on. With different languages come different paradigms. Leveraging the strong points of each language can make you more proficient in them, and is really the fun thing about learning new languages.

[genericdave]

I'm confused as to how "modeling with prototypes" is distinct from OOP. The differences seem to be rather insignificant when compared with, say, the difference between OOP and functional paradigms. This difference is something I'm currently wrestling with as I try to figure out if a language like Clojure would be well adapted to game programming. I'm beginning to thing that it's not worth the trouble.

[EmmanuelOga]

I'm confused as to how "modeling with prototypes" is distinct from OOP. The differences seem to be rather insignificant when compared with, say, the difference between OOP and functional paradigms.

Bingo! Using techniques as the ones described here: http://lua-users.org/wiki/ObjectOrienta ... reApproach

You get something that is almost the same as using classes, so the differences are almost only syntactical.

But behold there are no classes, only functions that returns objects (factories). You don't need to mark 'methods' explicitly as private/public/protected. And you don't need inheritance: if you need to expand the functionality of an object, use a second function to modify the object returned by a factory. Use decorators in place of a "super" keyword. For many uses you don't even really need to start messing with the prototypical inheritance chain (via the __index property), although this mechanism is very powerful and allow you to do things like summing or comparing two objects together with your own defined semantics, or convert objects to strings in a way that makes more sense than getting a table signature and an object id.

An example from a previous thread (http://love2d.org/forums/viewtopic.php?f=5&t=2620): http://pastie.org/1659847

So for me prototype modeling is about forgetting about classes, classic OOP inheritance chains and access restrictions. All you have are functions and objects.

[BlackBulletIV]

You get something that is almost the same as using classes, so the differences are almost only syntactical.

Not exactly. If use class dictionaries (lots of __index stuff) you can apply changes to the class at a later date, and all instances in existence will reflect this change. Not so with the closure method, only new instances will reflect it. That's one thing I don't like about using that method.

[EmmanuelOga]

You get something that is almost the same as using classes, so the differences are almost only syntactical.

Not exactly. If use class dictionaries (lots of __index stuff) you can apply changes to the class at a later date, and all instances in existence will reflect this change. Not so with the closure method, only new instances will reflect it. That's one thing I don't like about using that method.

Reopening classes to modify them on the fly is not strictly an OO feature. Many OO languages won't allow you to do that. In others were you can do that, you are encouraged not to or to do it sparingly.

On the other hand, you can still use global properties w/o class dictionaries very easily. Here is modification of the previous example to have color be global to all shapes:

http://pastie.org/1676176

[kikito]

Reopening classes to modify them on the fly is not strictly an OO feature. Many OO languages won't allow you to do that. In others were you can do that, you are encouraged not to or to do it sparingly.

I'm going to say something that might be controversial, but there it goes: Closed clases are wrong. The languages that use them make the lifes of the compiler-makers and language-designers (tens of people) easier at the cost of making the lifes of the language-users harder (potentially millions).

Fortunately, Lua isn't bound to that constraint. At least on middleclass, re-opening existing clases is possible, easy, and encouraged. In fact, every new method added to a class re-opens it. And secondly, mixins are a supported and accepted way of "sharing functionality" between classes easily. (middleclass-extras is based exclusively on mixins).