4 ms·

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

• zzzcpan 12y ago
  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() vs 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.
  • deleted 12y ago
    [deleted]
  • Rusky 12y ago
    Pass an object to DoSomething and you get the same thing as the closure.
    • mytochar 12y ago
      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());
  • tel 12y ago
    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)
    • zzzcpan 12y ago
      Ok, you are right. I was confusing implementation with the concept.
  • Sanddancer 12y ago
    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.