3 ms·
I'm reminded of "Closures and Objects are equivalent" (http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquiva
by gamegoblin 12y ago
I'm reminded of "Closures and Objects are equivalent" (http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent)
That being said, you can easily create a data type in Haskell that contains a bunch of "methods" that live in the IO monad and mutate other bits of data the object contains that also live in the IO monad, but it's a bit of a forced paradigm.
- dllthomas 12y ago'I'm reminded of "Closures and Objects are equivalent"' Sure, though to be clear I'm not taking any position on that question above. I just think that the pattern solidly fulfills all of the criteria he gave, and it's not a terrifically obscure one. 'That being said, you can easily create a data type in Haskell that contains a bunch of "methods" that live in the IO monad and mutate other bits of data the object contains that also live in the IO monad, but it's a bit of a forced paradigm.' I think what you're getting at here is that persistent identity and mutable state are necessary parts of IO? It's clear that they're often assumed to be; I've encountered the question before and I lean weakly "no", although not with confidence. More importantly, they are explicitly disclaimed as being an inherent part of IO as defined in the article, so were not what I was speaking to. I agree that an IO-backed message passing object framework 1) could be built in Haskell and 2) would not be a natural fit.
- dllthomas 12y ago... necessary parts of OO.