Contexts as Objects

[kinghajj]

I wrote a post at http://kinghajj.blogspot.com/2007/09/contexts-as-objects-in-newlisp.html">//http://kinghajj.blogspot.com/2007/09/contexts-as-objects-in-newlisp.html detailing how to use contexts to implement classes and objects in newLISP. I've just discovered this--though I'm probably not the first--so I haven't found out all that you can do with this.



Hope you enjoy it.

[cormullion]

i did! thanks...

[kinghajj]

I thought that you might have found this already. Is there a link to where you describe it?

[cormullion]

I meant - I did enjoy your post. :-)



I know very little about object stuff. There's been some sporadic discussion on the board in the past - eg



http://www.alh.net/newlisp/phpbb/viewtopic.php?t=1058">//http://www.alh.net/newlisp/phpbb/viewtopic.php?t=1058



But I'm still at the basic stages and haven't made much use of it.

[Jeff]

Keep in mind that all contexts, including context prototypes, are children of MAIN.  You therefore cannot create objects that store objects (at least using contexts).  But lisps work better with functional programming than OOP.

[Dmi]

But lisps work better with functional programming than OOP.

Hmm... Is there some article about functiolal vs OOP design?

Many of us coming to newLISP from procedural/OOP world, we all need in examples about successful functional technics, that can replace OOP, I think.

[Jeff]

I'm sure there probably is, but probably not specifically related to newLISP.  I'm sure I could write one this week, though.  I'll post it when it's done.

[Dmi]

It would be cool, Jeff!

[Jeff]

Here is a quick write-up:



http://artfulcode.nfshost.com/files/functional-programming.html">http://artfulcode.nfshost.com/files/fun ... mming.html">http://artfulcode.nfshost.com/files/functional-programming.html

[Dmi]

http://artfulcode.nfshost.com/">http://artfulcode.nfshost.com/ - Site Temporarily Unavailable

[Jeff]

Yeah, I know.  They are moving the servers to a new (physical) location.  They did it at the last minute.  They will be back up soon, hopefully.

[Dmi]

Very nice, Jeff!

I like your examples and explanation tricks!



But there is nothing versus OOP.

Personally, me thinking that good design plus lispish tricks are sufficient to not to use OOP in 95% cases. But this requires different code planning strategy.



I looking for a document which can explain (with examples) how to successfully build _really_ big programs using down-to-up programming, language-building-language etc. tricks - all this words looks beautiful, till U start to construct something bigger than 1000 lines of code yourself :-



Unfortunately, english isn't my native, so I can't briefly overlook all-the-books-around - and I looking for some recommendations.



I want to look at "OOP design vs functional design" explanation like U explain "procedural coding vs functional coding" styles.

[Jeff]

It is more intuitive to compare functional code to imperative code, rather than to OO or procedural or whatever.  OOP is a technique of storing namespaces along with functions to manipulate their data.



Any comparison I could come up with would give you the wrong idea.  You want to just forget OOP for a moment and stop thinking about programs as a series of commands.  Think in terms of list manipulation.  Think about (map).



In OOP, you have an object that manipulates itself or performs actions on its own behalf.



With functional programming, you might have a list or items.  Rather than each of those items performing actions on their own behalf, you would map the manipulator function to each of those items, creating a new list with the new values.



Here is a quick comparison of OO vs functional.  I want to change a list of characters to uppercase.



OOP (using Python for simplicity):

Code Select Expand

class Character:
  def __init__(self, char):
    self.char = char
  def capitalize(self):
    return self.char.capitalize()

class CharacterGroup:
    def __init__(self, *args):
        self.chars = []
        for c in args:
            self.chars.append(Character(c))
    def capitalize(self):
        for c in self.chars:
            yield c.capitalize()

group = CharacterGroup("a", "b", "c", "d")
for c in group.capitalize():
    print c

The functional solution would be something like:

Code Select Expand

(let ((chars '("a" "b" "c" "d")))
  (map println (map upper-case chars)))

[Dmi]

OOP is not for coding. It's mainly for projecting.



(map) etc. are low level functional coding techniques. Their analogs is imperative/procedural programming, not OOP.



OOP is firstly a proper object decomposition, that itself is really declarative. Imperativness is only in method implementations and it isn't so interesting.



OOP offers to a programmer a mechanism of assembling and interoperation of pieces of code, that implements a different behavior (OOP GUI design is very effective)



OOP offers a way for interface specification (like JavaBeans are).



OOP isn't need for upper-casing etc, I think :-) Many fully procedural languages have many nice tricks for that.



But how about all the OOP benefits in a functional lispish style? Yes, we must forget OOP for that, but what will be in place of it?

[Jeff]

Well, upper-casing characters is obviously a contrived example, but it shows the difference well.  OO is a way of defining complex types.  The need for overly complex types is a fundamental lack of good types in a language.  Although I do wish that newLISP had defstruct :)



Common Lisp has CLOS (common lisp object system) and Scheme can sort of fudge OOP, but most lisps kind of look down on OO.  newLISP can do prototyping using contexts (which is super handy for many things, but not so great for OOP).