What benefits did you get from FOOP?

[csfreebird]

I just took 2 days to refactor my newlisp code, applied FOOP to my application.

From what I experienced, FOOP helps me to orginize my code better than before,



1. I have a Sign class, after creating sign object, use sign object's attributes to hold status to avoid passing agruments between one function to another function.



2. Also, Object Oriented design makes calling code looks simple

Code Select Expand


(new Class 'Sign)
(load "sign.lsp")

(define (create-sign server port sign-id)
  (let (sign (Sign server port sign-id))
    (:launch sign)))


It seems the benefits that I got is just related to Object Oriented. Do I miss something about 'F' (Functional)?

How do you think? What other benefits did you get from FOOP?

[Astrobe]

I think the real benefit of the features of what is called FOOP is the ability to overload functions. It always feel a little dumb to me to have to write e.g. (openFile sourceFile); FOOP features allow for writing (:open sourceFile) and (:open sourceWindow) and this is great.



That said, I don't like the name, because FOOP is neither really "functional" (no immutability) nor really "OOP" (awkward inheritance) if one is a slight bit purist. The same feature could be achieved without (self), if only Newlisp passes the 'object' to the 'method':



(define (Person:name p) (p 1))

(set 'foo '(Person "JohnDoe"))

(println (:name foo))



I've hacked my newLisp to just do that, and it actually saves a few lines of code in the interpreter. I have yet to determine, though, if the extra parameter doesn't slows down too much compared to the 'self' version. I believe that Newlisp's ORO model makes it more interesting to move towards the functional paradigm rather than the Object paradigm. Apparently newLisp has evolved in the opposite direction.

[Lutz]

This is actually the way FOOP started out originally and during the prototyping phase the colon operator was coded in newLISP. The self operator was introduced later to make mutability possible if wanted.

[jopython]

What is DUMB about (openFile sourceFile)?  It seems so natural to me.

I think the real benefit of the features of what is called FOOP is the ability to overload functions. It always feel a little dumb to me to have to write e.g. (openFile sourceFile); FOOP features allow for writing (:open sourceFile) and (:open sourceWindow) and this is great.

[Astrobe]

What is DUMB about (openFile sourceFile)?  It seems so natural to me.

Simply that one "visually" repeats that one deals with a file. There are minor implications too: more typing, and on systems that manage a shared pool of strings "openFile" being unique, it takes its own space; whereas if it's just "open", the "pointer" to the existing symbol name (e.g. for windows) may be reused.

[Lutz]

The F in FOOP



 When you do:

Code Select Expand


> (new Class 'Person)
Person
> (Person "JohnDoe")
(Person "JohnDoe")
>

The statement (Person "JohnDoe") returns the same as an object. The object is the functional statement to create itself. The constructor functor Person is also the class id.

[Astrobe]

The F in FOOP



 When you do:

Code Select Expand


> (new Class 'Person)
Person
> (Person "JohnDoe")
(Person "JohnDoe")
>

The statement (Person "JohnDoe") returns the same as an object. The object is the functional statement to create itself. The constructor functor Person is also the class id.

I'm sorry but it makes little sense to me. (Person "JohnDoe") is technically an expression, not a statement. It is indeed functional in the sense that it is a pure function, but so is (fn (x y) (+ x y)). The fact that Person is both in the result and is a class id is a neat generalisation of type tags that dynamic languages usually use internally. Calling statements or expressions "functional" doesn't make the language more functional.



If you talk to functional people, they'll tell you that the two main ideas of functional programming are immutability and side-effects management. When I removed (self), I overlooked the fact that (self) allowed to mutate the object, something that I cannot do any more because now the 'methods' receive a copy of the original object. To make it usable again, the method must return a new object:

(define (Person:rename p nn) (setf (p 1) nn) (p))

And that's exactly what a functional program does. Of course it has the downside of creating objects, but that's all the story about functional programming: mutability is a shortcut that saves memory and CPU cycles, but it can become a drawback (for debugging, for the gc, in the presence of threads, etc). If you observe functional programming languages, many features are there in order to deal with the lack of mutability.



Now if we talk about the OOP part, the first thing one could note is the lack of direct support for inheritance. As far as I understand it, (def-new) and (context)'s second syntax is supposed to help with that. The idea of inheritance is that the derived class "understands" the messages defined in its base class even though it doesn't define them explicitly.

What if we do:

(new Class 'Person)

(Person "JohnDoe")

> (Person "JohnDoe")

(new SubClass 'Person 'Worker)

(Worker "JaneDoe")

>((Person Worker) "JaneDoe")



The newlisp engine could loop over the list in the first item until it finds the desired method symbol in the context.

[bairui]

Newlisp's (F)OOP Inheritance:

Code Select Expand

(new Class 'Person)
(define (Person:name) (self 1))
(define (Person:salary) 0)

(new Person 'Worker)
(define (Worker:salary) (self 2))

(setf people '())
(push (Person "John Doe") people)
(push (Worker "Jane Doe" 3000) people)

(define (describe person)
  (string (:name person) " earns " (:salary person) " dollars."))

(map describe people)

[Astrobe]

Ok my bad.

[m i c h a e l]

Hello fellow newLISPers! Long time no speakie.



At the time "FOOP" was born, it was functional because of its immutable objects. Soon, however, FOOP lost its functional nature and became what it is today (the right choice, in my opinion). That left FOOP's poor "F" without its original meaning. I jokingly offered some possible alternatives in one of my FOOP videos, but by then the name had stuck.



I'll readily admit FOOP is not object-oriented in the strict sense, but it definitely improves the experience of developing OO code in newLISP.



m i c h a e l