Glurk wrote:
However, on the other hand, I wonder how it ties in with real world systems that do in fact do deal with objects that change state.
Do they change state? Or do you see a new object with a different state than the previous object? Can you step into the same river twice?
For example, if I was building a library system - I might have book objects, and if a book gets borrowed, there remains the same book object, but it now just has a different state - from "on shelf" say, to "borrowed".
Now, in Haskell, I might have a function to lend a book :-
lend book1
and this is going to return a new book, with the appropriate status change.. ..but what of the old book ? I don't want 2 book objects floating around.. ...to my way of thinking, it's really not a new book, it really is a change of state.
How do people see this kind of situation ? Is it just the way of looking at it... ? Do I just accept that I toss out my old library object, and have a new one, which happens to be the same as the old one, except for the "new" book which is now borrowed ?
Do I really need to get over thinking of objects in the first place, even though it's what I see exist in the real world ?
As Master Apfelmus has written, what you see (or what you think you see, if that is different) is almost completely irrelevant to what is going on in your program in the computer. If you lend a book, the book doesn't change. The library doesn't change. What changes is a model of the library, which now indicates that a book is lent to someone, and the real question is how best to build that model of the library. Most object oriented languages are inherently procedural; this is equivalent to writing all of your code in the IO monad. Haskell gives you more options than that, including writing pure functional code with the type lend :: Book -> Library -> Library which has all sorts of neat properties that help you build the model without falling into some of the potholes that go along with procedural programming.
Is there where we part company with non mutability and venture into the monads where we do have side effects ?
At some point, you will ask, "What about these two Libraries floating around?" and realize that what you really need is a monad and ideally one specific to your Library (rather than the general IO monad). Then you will be enlightened. -- Tommy "Gotta cut down on the cold meds" McGuire mcguire@crsr.net