| I've read http://www.paulgraham.com/noop.html (Why Arc isn't Especially Object-Oriented) and I mostly agree on all points. There is still one argument that I truely appreciate with OO thought (and that wasn't really debated in this article): clear abstractions. When I jump into a new project, I really appreciate when functionalities are clearly separated -- might it be OO or not. Who likes spending 15mins reading code only to find out that the useful part was somewhere else? (Ok, it depends of the actual code.) I understand that OO is overkill for many tasks and that arc usually offers better alternatives. However, as pointed out in the article, it doesn't mean that OO is never useful. For instance, with python, I like the fact that even if String has a "join" method, it doesn't stop me from using that name in my code. Anyhow, here's my idea about a simple arc-ish OO. This: (let s (Socket "irc.freenode.net" 6667)
(on-receive s [prn _])
(send s "nick d0m\n"))
Would be transformed to: (let s (Socket "irc.freenode.net" 6667)
(s 'on-receive [prn _])
(s 'send "nick d0m\n"))
Socket might be defined this way: (defobj Socket arg
(let o
(obj 'on-receive (fn (..) ..)
'send (fn (..) ..))
(apply (o (car arg)) (cdr arg))))
and defobj could someway let the interpreter know that Socket is an object and that:
(send (Socket) ..) should be evaluated as ((Socket) 'send ..)Arc has hundreds of function and it might feel overwhilming for beginners.
This might be a way to guide them through everything Arc has to offer. Finally, the fact that string are callable such as:
("hello" 0) -> h
proves that OO isn't as useless as we might think..
In this example, "hello" is clearly an object. | 
