# Are class methods closures?

closure ... is a function or reference to a function together with a referencing environment

At the same time in the wiki article about class methods:

Accessor methods are used to read data values of an object. Mutator methods are used to modify the data of an object.

So, can I say that data is environment and class methods (accessors and mutators) are closures?

A closure is a piece of code together with an environments providing a binding for its identifiers. In the case of a method, the identifiers (at least some of them) are bound to data in specific instances of the class, not just to the class itself.

The method provides only the code, of the function (in your first quote), while the environment is provided by an instance of the class (an object in your second quote). So it is the method together with the object (class instance) that forms a closure.

Indeed, the class instance may be seen as the closure, since it naturally carries the methods with itself formally, considering that it is a closure for a tuple of functions, rather than a single one. That is actually necessary, since the code of each function may refer to the other function, meaning implicitly for the same environment.

Some of the first implementations of object orientation were actually produced that way with higher order language. The creation of an instance of a class was done by calling a creation function $Foo$ with proper parameters. This function would return an instance represented by a tuple of functions closed over the local environment of $Foo$, each function being one of the methods for the class. Actuallly these method function were declared inside $Foo$ so as to see all the local identifiers in $Foo$, which are the data for this instance being created, and otherwise invisible outside $Foo$.

Each new call of $Foo$ would create a new call instance, i.e. a new environments on which execute the methods.

But the syntactic sugar may vary significantly.

Historically, afaik, the name closure was used for a function value $g$ returned by a call to a function $F$, though it is created (declared, to say it approximately) inside $F$ and can thus see and use any entity $x$ declared in $F$. Normally, what is declared in $F$ ceases to exist, to be accessible, as soon as $F$ is exited. But when $F$ returns such a function valued result $g$, the system has to preserve any identifier $g$ may be using since $g$, as a function value, survives the termination of the call to $F$. All identifiers used by $g$ are preserved in an environment and $g$ together with this environment is called a closure.

Note that $g$ is a function value, not anything being called. The environment of this closure is preserved as long as the function is callable. Several function can be closed at the same time on the same environment.

There is a parallel between instance methods of an OOP class and a group of closures that all close over the same group of variables.

One way to implement objects is to create a group of closures within a function (the constructor) that binds the variables (acting as instance variables). This approach will return those closures in a data structure such as a JavaScript "map" that allows other code to select and call the closures by method name.

This approach does not allow creating subclasses with direct access to their inherited instance variables, nor debuggers that can access the instance variables. That's because they're tightly locked up by the closures.

Conversely, one way to implement a closure is with an object instance that contains the closed-over state and has the desired call() method with the desired arguments, implementation, and and results.