On Jan 23, 9:15 pm, Ashley Moran <[email protected]> wrote: > On 22 Jan 2011, at 02:38, Rick Moynihan wrote: > > > Well objects are not really a well defined term. However I'd think of > > an object being data + behaviour (methods), where both the data and > > behaviours move around together. > > There's (yet another...) definition of OO in the video interview Ralph > Johnson, Joe Armstrong on the State of OOP[1]. I think of OO as more about > messaging and behaviour than data, but then, I can't say I've written OO code > without encapsulating the data behind a layer of messages.
Yes, that's the traditional smalltalk view of OOP, infact Alan Kay frequently argues that message passing was the more neglected idea and that messages form the negative space between objects. Erlang clearly bears some similarities with its actors to OOP and message passing, however, though Erlang's actors encapsulate state (as part of a tail recursive function call) and provide behaviour, they are not extensible. Clojure's agents are superficially similar to Erlang's actors in that they contain state, are asynchronous and sit on top of a message queue. However they don't define behaviour, instead they just hold a value. In Clojure behaviours (functions) are then sent to the agent from the outside as messages, these functions are then queued and executed sequentially on a thread pool, operating on the contained state with the return value of the function becoming the new value of the agent. In this way Clojure's agents are far more dynamic and open to extension. Also because Erlang always assumes a distributed model (even when in process) reading values from an actor can be slow as the query will block in a queue (possibly behind a long line of other requests). In Clojure readers never have to wait and never block, simply dereferencing an agent will instantly return a stable snapshot of its value. > >> I'd like to know if Clojure uses a similar convention for OO or if it does > >> something different. > > > The code above is obviously workable, and occasionally you might see > > things like that, but Clojure isn't an OO language and doesn't really > > want to be. Instead Clojure lets you choose the features of OO > > independently, allowing you to pick'n'mix as you please: > > > - Polymorphism > > - Identity > > - State > > - Namespaces > > - Hierarchy > > > Rich Hickey argues that conflating all these notions inside one (or > > two) language construct (the object) (and the class) often has > > undesirable consequences, and that they're more useful independently. > > Having used Clojure, I'd agree :-) > > I haven't used Clojure yet, so I can't comment. But I'd be interested to try > it to see how it breaks these concepts apart. I might stalk you all at the > next Clojure Dojo :) By all means, I'll be happy to help... R. -- You received this message because you are subscribed to the Google Groups "NWRUG" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nwrug-members?hl=en.
