3 ms·
Now you have made me curious. Do you have any pointers to some source material about "pure objects"? I find it especially interesting because under normal circ
by shadowfox 13y ago
Now you have made me curious. Do you have any pointers to some source material about "pure objects"?
I find it especially interesting because under normal circumstances an object with no mutable state is no different from a collection of methods (which can be encapsulated in different ways of course; say as an OCaml module).
So I am curious as to what advantage an object system that allows only pure objects provide.
- silentOpen 13y agohttp://caml.inria.fr/pub/docs/manual-ocaml/manual005.html#toc30 http://caml.inria.fr/pub/docs/manual-ocaml/manual005.html#to... If you have only pure objects, you can still perform open recursion and leverage structural polymorphism (including row variables). Additionally, your objects are just values and, because they aren't mutable, can be held for backtracking. For instance: ```ocaml class virtual biggable x = object val x = x method x : int = x method virtual embiggen : biggable end let o = object (self) inherit biggable 0 method embiggen = {< x = x + 1 >} end let q f o = object (self) val x = o#x method x = x method embiggen = f {< x = x * 2 >} end let a = q (q (fun x -> object inherit biggable x#x method embiggen = {< >} end)) o#embiggen ;; # a#x;; - : int = 1 # a#embiggen#x;; - : int = 2 # a#embiggen#embiggen#x;; - : int = 4 # a#embiggen#embiggen#embiggen#x;; - : int = 4 ```
- Fishkins 13y agoIt's the topic of the third week of Martin Odersky's Scala FP course: https://www.coursera.org/course/progfun https://www.coursera.org/course/progfun
- andolanra 13y agoThe William Cook paper 'On Understanding Data Abstraction' gives a basic formulation of pure objects. Crucially, an 'object' needn't be what the language itself calls an object, e.g. I could write up a 'set object' in Haskell, which does not have objects: data Set elem = Set { contains :: elem -> Bool } insert :: (Eq elem) => elem -> Set elem -> Set elem insert key set = Set { contains = c } where c key' = if key == key' then True else contains set key union :: (Eq elem) => Set elem -> Set elem -> Set elem union set1 set2 = Set { contains = c } where c key = contains set1 key || contains set2 key emptySet :: Set elem emptySet = Set { contains = (\ _ -> False) } -- mySet corresponds to {1,2,3} mySet :: Set Int mySet = insert 3 (insert 2 (insert 1 emptySet)) -- myVal is True myVal :: Bool myVal = contains mySet 2 Depending on your definition of object-oriented programming, this could be considered an object or something else. William Cook argues that it's an object because access depends only on a public interface, i.e. I could add another implementation fromList :: (Eq elem) => [elem] -> Set elem fromList list = Set { contains = c} where c key = key `elem` list which uses a different representation underneath the surface, but the previous implementations of union and insert will work with it because it exposes the same interface... which is not the case with ML/OCaml modules, which must select a single implementation. This is a simplified version of the example Cook himself uses, so I urge you to read the paper if you want to understand more. (On the other hand, people in the Smalltalk/Ruby/&c camp will say, "No, of course that's not object-oriented—you're not sending messages!" So... it's a complicated debate.) [1]: http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf http://www.cs.utexas.edu/~wcook/Drafts/2009/essay.pdf also linked by https://news.ycombinator.com/item?id=6084465 https://news.ycombinator.com/item?id=6084465