Closures + Lambda = The key to OOP in Lisp(lispy.wordpress.com)
lispy.wordpress.com
Closures + Lambda = The key to OOP in Lisp
http://lispy.wordpress.com/2007/07/18/closures-lambda-the-key-to-oop-in-lisp/
7 comments
Sheesh.. Why? I don't understand why people keep trying to take something which is inherently non-object-oriented (Lisp) and cram an object-oriented mentality into it. Sure, it's nifty you can make objects without using the Common Lisp Object System, but that's generally not how you'd want to structure an actual application, right? Lisp is so powerful you can build and manipulate your own structures at runtime, so you don't need to make objects which represent a concept. Those concepts are represented through utility functions. Maybe I'm just dumb, but I don't see it.
This is an exercise that's being done just for the fun of it to explore what (for me) were cryptic remarks from people like Graham and Norvig.
I wanted to work on something that would force me to write macros. Obviously, to make the code for "classes" that construct object generating functions like the one in the example will be written by... macros. So I successfully put myself in a situation where macros were the natural answer... and saw what I needed to do. My getting to that particular ah-ha moment was the real message of the post. I can now begin to understand what the experts are talking about.
So I can now use closures and macros to make lisp just as crappy as other programming languages... or I can use this knowledge to learn more about doing things "the lispy way." Trust me when I say that the latter option is my preference.
I'm just an amateur that's excited about these ideas... and that you _can_ do this sort of thing. I'm not saying that you _should_.
I wanted to work on something that would force me to write macros. Obviously, to make the code for "classes" that construct object generating functions like the one in the example will be written by... macros. So I successfully put myself in a situation where macros were the natural answer... and saw what I needed to do. My getting to that particular ah-ha moment was the real message of the post. I can now begin to understand what the experts are talking about.
So I can now use closures and macros to make lisp just as crappy as other programming languages... or I can use this knowledge to learn more about doing things "the lispy way." Trust me when I say that the latter option is my preference.
I'm just an amateur that's excited about these ideas... and that you _can_ do this sort of thing. I'm not saying that you _should_.
Allow me to introduce you to my corollary to Greenspun's Tenth Rule: "Any sufficiently complicated Scheme or Lisp program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of object orientation."
I must never have written a sufficiently complicated Lisp program.
"when it comes to encapsulation, the very foundation is that all state must be accessible only from inside the object's methods."
Screw encapsulation then. Low tech data abstraction gives you most of the benefits without the hassle. (+)
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...
(+) Edit: was "The real point is data abstraction."
Screw encapsulation then. Low tech data abstraction gives you most of the benefits without the hassle. (+)
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-14.html...
(+) Edit: was "The real point is data abstraction."