[closures] Concept examples and explanation needs improvements

[Jasstkn]

Hi.
While I was learning concepts for JavaScript I found out that closures theory isn't very helpful for solving the suggested practical exercise: Coordinate Transformation.

I would like to propose to improve it by

• adding a more advanced example with an explanation for using a function in return
• explain how to work with its arguments then.

Let me know what do you think.
Connected links are here:
https://exercism.org/tracks/javascript/concepts/closures
https://exercism.org/tracks/javascript/exercises/coordinate-transformation

[junedev]

Creating an issue about improving the closure concept was on my todo list. 🙂

In addition to adding to the existing concept documents I think it would also be good to maybe rework/simplify some of the existing content.

Do you want to work on this?

[Jasstkn]

Creating an issue about improving the closure concept was on my todo list. 🙂

In addition to adding to the existing concept documents I think it would also be good to maybe rework/simplify some of the existing content.

Do you want to work on this?

Yes. I can try :)

[khendrikse]

Hi @junedev! I don't know if this is the place for this, but I notice something about the closure explanation.

In the explanation it says:

"Closures are a programming pattern in JavaScript which allows variables from an outer lexical scope to be used inside of a nested block of code. JavaScript supports closures transparently, and they are often used without knowing what they are."

// Top-level declarations are global-scope
const dozen = 12;

{
  // Braces create a new block-scope
  // Referencing the outer variable is a closure.
  const twoDozen = dozen * 2;
}

// Functions create a new function-scope and block-scope.
// Referencing the outer variable here is a closure.
function nDozen(n) {
  return dozen * n;
}

But most explanations, including the one on MDN define a closure as being A closure is the combination of a function bundled together (enclosed) with references to its surrounding state (the lexical environment). In other words, a closure gives you access to an outer function’s scope from an inner function. (source: MDN on Closures

In the explanation it says that referencing the outer variable from the first block scope would already be a closure. Looking at the docs from MDN, that would then not seem to be correct, as that first block scope is not a function?

I'm mostly asking because it is confusing me as well, and as closures are a hard concept to explain, I wonder if we might need to make sure this explanation is correct.

[junedev]

Great question! I am not 100% sure myself. @SleeplessByte, what's your opinion on this? Would you can the block example a closure as well?

In any case, I would recommend making all the main content about the function version of closures as this is what most people think of when they hear the term and how they are mostly used. Then if we decide the blocks count as closures as well we can add that as an additional knowledge nugget in about.md.

[khendrikse]

I'm curious what @SleeplessByte thinks (if only to learn ;)), if y'all think it's better to delete the first shown block-scope, let me know, I'll remove it and open a PR.

[junedev]

@khendrikse Either @Jasstkn will already incorporate this in their current re-work of the concept files or it can be addressed afterwards. In any case, I would like to avoid you and @Jasstkn working on the same files at the same time.

[khendrikse]

That is also fine :)

[SleeplessByte]

Sooooo. 👋🏽

Definitions are as difficult as naming is (I wrote articles about similar subjects in the past, for example: JavaScript, Ruby, and C are not call by reference), which is what makes this even more interesting. Yes, in general closures are often defined as enclosing values inside a function, which is often possible in languages that "do not treat functions as a special case" (meaning functions are first-class citizen, and can be passed around, just like other values). This is usually mentioned because if you can pass functions around, it means you can often execute the function on a completely different call site then where it was defined. The operational bonus is then that that function has access to variables it had access to when it was defined despite the call site NOT (necessarily) being able to access those.

Okay. Great.

In JavaScript blocks (the first example) cannot be passed around, but in some other language (hello there Ruby), some forms of blocks are callable (effectively making them similar or the same as functions), ánd can be passed around.

Because the block from the example is static/fixed in place, its power to enclose the variable is "lost". It doesn't matter. Therefore I would agree to bin the example, despite you probably being able to find references where a writer argues that any enclosure is "a closure". I'm not willing to say that we absolutely cannot call this a closure, but in general, when people who know JavaScript or similar languages talk about closures, they will almost always refer to instances of functions that enclosed variables, and thus not talk about blocks.

TL;DR; correctness of the first example doesn't matter. It's use-case is basically none (other than creating a new block which can be great when writing switch statements and their cases. I would vote to remove it.

---

✨ Everything that follows is just extra information and should not be included in this exercise

Are there other ways to enclose other than using a function?

Yes! For example classes can do this too.

const definedOutside = 'hello, world!'

export class Shout { 
  // This function is technically a closure
  call() { console.log(definedOutside); }
  
  // This variable is, once this proposal becomes language,
  // technically enclosing a value from outside this class, but will
  // probably not be called a closure
  #privateVar = definedOutside
}

const utterance = new Shout()

utterance
// => Shout {#privateVar: 'hello, world!'}

utterance.#privateVar
// => SyntaxError Private field '#privateVar' must be declared in an enclosing class

utterance['#privateVar']
// => undefined

utterance.call()
// => 'hello, world!'

Classes can in fact enclose values passed from the outside in their constructor, variables created in their constructor, or even variables attached to themselves

export class Enclosing {
  constructor(passedValue) { 
    let increment = 0
    
    this.magicNumber = 21
    const self = this;
     
    // Return a new object that does NOT have Enclosing as its prototype

    return {
      // encloses variable defined in constructor
      increase() { 
        increment += 1
        return increment;
      },
      
      // encloses variable passed in constructor
      call() { console.log(passedValue); },

      // encloses the entire object that was created by the constructor
      ref() { return self.magicNumber * 2 }
    }
  }
}

// Now try it out
const enclosed = new Enclosing('Goodbye, Mars!')

enclosed.magicNumber
// => undefined

enclosed.increase()
// => 1

enclosed.call()
// => "Goodbye, Mars!"

enclosed.ref()
// => 42

[khendrikse]

Thanks so much @SleeplessByte ☺️ I learned a lot and this made it very interesting! I am glad I decided to ask. (Also, this read as well as a blog already haha).

[SleeplessByte]

No problem! Gewoon blijven vragen :)

[junedev]

@Jasstkn How is it going? Do you still want to work on this?