Of course it's not a hard-and-fast distinction: you can have a closure that dispatches on one of its parameters to do one of several different things, and you can have an instance with only one method. But it's usually valid.

Imagine you have a closure with a function that takes in a string and a list and returns a list. Depending on implementation of the function, you could have the string be the operation you wish to perform. The method name, and the list be the parameters. The returned list is the output.

Getters could pass an empty list and return a list with one entry

Setters could pass a list with a value and return an empty list

And so on :)

Like this:

   func NewClosure() func(string, ...float64) []float64 {
      x := float64(0)
      return func(method string, args ...float64) []float64 {
         if method == "setX" && len(args) > 0 {
            x = args[0]
            return nil
         } else if (method == "getX") {
            return []float64 { x }
         } else {
            panic("invalid method")
         }
      }
   }

   a := NewClosure()
   b := NewClosure()
	
   a("setX", 50)
   b("setX", 12)
	
   fmt.Printf("a.X = %v, b.X = %v", a("getX")[0], b("getX")[0])

I like it.

[edit: added working example .. and realized I'm adding to what my parent poster was saying]

Consider this simple syntactic rule: `obj.x` <=> `obj("x")`. With this rule, the usual syntax for a method call, `obj.method(x)`, literally becomes the curried application of a closure, `obj("method")(x)`. You could also add a rule like `obj(x) = y` <=> `obj(set(x, y))`. Then you could define objects a bit like this:

    point = (x, y) -> method ->
        match method:
            "x" -> x
            "y" -> y
            set("x", newx) -> x = newx
            set("y", newy) -> y = newy
            "add" -> (pt) -> point(x + pt.x, y + pt.y)
    p = point(1, 2)
    p.x = 5
    print p.add(point(3, 4))

  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
  })

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)

   DoSomething(func() { ... })

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

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

   DoSomething(new MyAction());