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.
prototype modeling as an alternative to OOP
- EmmanuelOga
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
prototype modeling as an alternative to OOP
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- genericdave
- Citizen
- Posts: 53
- Joined: Tue Dec 15, 2009 9:08 am
Re: prototype modeling as an alternative to OOP
I'm so lost. I agree that lua is pretty sweet, however.
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: prototype modeling as an alternative to OOP
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.
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.
When I write def I mean function.
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: prototype modeling as an alternative to OOP
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.
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
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: prototype modeling as an alternative to OOP
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:
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.
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 ).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.
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.
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- genericdave
- Citizen
- Posts: 53
- Joined: Tue Dec 15, 2009 9:08 am
Re: prototype modeling as an alternative to OOP
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
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: prototype modeling as an alternative to OOP
Bingo! Using techniques as the ones described here: http://lua-users.org/wiki/ObjectOrienta ... reApproachgenericdave wrote: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.
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.
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- BlackBulletIV
- Inner party member
- Posts: 1261
- Joined: Wed Dec 29, 2010 8:19 pm
- Location: Queensland, Australia
- Contact:
Re: prototype modeling as an alternative to OOP
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 wrote:You get something that is almost the same as using classes, so the differences are almost only syntactical.
- EmmanuelOga
- Citizen
- Posts: 56
- Joined: Thu Apr 22, 2010 9:42 pm
- Location: Buenos Aires, Argentina
- Contact:
Re: prototype modeling as an alternative to OOP
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.BlackBulletIV wrote: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 wrote:You get something that is almost the same as using classes, so the differences are almost only syntactical.
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
--------------------------------------------------------------------------------------------------------
http://EmmanuelOga.com
http://EmmanuelOga.com
- kikito
- Inner party member
- Posts: 3153
- Joined: Sat Oct 03, 2009 5:22 pm
- Location: Madrid, Spain
- Contact:
Re: prototype modeling as an alternative to OOP
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).EmmanuelOga wrote: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.
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).
When I write def I mean function.
Who is online
Users browsing this forum: No registered users and 3 guests