Hacker News Reader

Comment by tel | Hacker News Reader

I'm not sure that I would agree here. Do you have a simple example?

  foo.DoSomething()
  ... // remember not to return 
      // without foo.Done() called
      // (EDITed for clarity: 
      // foo is the state, that changes,
      // so you have to keep track of 
      // its changes)
  foo.Done()

  DoSomething (func(){
     ... // don't have to remember 
         // a thing, no side-effects, 
         // equivalent of .Done() is
         // called afterwards for you
  })

EDIT2: exact behavior is not the point, keeping track of things is.

Pass an object to DoSomething and you get the same thing as the closure.

Java's Runnable interface was an example of this in practice. Rather than passing a function, you passed an object whose primary purpose was to carry around a function that would be called.

   DoSomething(func() { ... })

becomes

   DoSomething(new Runnable() {
      public void run() { ... }
   });

or the longer form

   class MyAction implements Runnable {
      public void run() { ... }
   }

   DoSomething(new MyAction());

That doesn't seem to have anything to do with objects versus closures. In both cases the right answers is absolutely to pass a function to DoSomething be it a function or a method.

If you're considering a language deficient of functions then we can take advantage exactly of the idea that objects can embed functions by having a "callable" thing.

    foo#doSomething (object
      method call : unit -> unit =
        ...
    end)

Ok, you are right. I was confusing implementation with the concept.

Classes don't need to have mutable state. I've written several rather useful classes that were completely immutable after initialization. As such, there are no things to keep track of. No side-effects, nothing like that, a snapshot in time of whatever values I need to pass elsewhere.

Reply on news.ycombinator.com