Why passing parameters to anon function when creating scoping

Question

Sorry, the title sucks but I couldn't think of a better one.

The ShadowDOM.js file in Polymer does this:

(function(scope) {
  "use strict";
  var unsafeUnwrap = scope.unsafeUnwrap;
  var wrap = scope.wrap;
  var nonEnumDescriptor = {
    enumerable: false
  };
  function nonEnum(obj, prop) {
    Object.defineProperty(obj, prop, nonEnumDescriptor);
  }
  function NodeList() {
    this.length = 0;
    nonEnum(this, "length");
  }
  NodeList.prototype = {
    item: function(index) {
      return this[index];
    }
  };
  nonEnum(NodeList.prototype, "item");
  function wrapNodeList(list) {
    if (list == null) return list;
    var wrapperList = new NodeList();
    for (var i = 0, length = list.length; i < length; i++) {
      wrapperList[i] = wrap(list[i]);
    }
    wrapperList.length = length;
    return wrapperList;
  }
  function addWrapNodeListMethod(wrapperConstructor, name) {
    wrapperConstructor.prototype[name] = function() {
      return wrapNodeList(unsafeUnwrap(this)[name].apply(unsafeUnwrap(this), arguments));
    };
  }
  scope.wrappers.NodeList = NodeList;
  scope.addWrapNodeListMethod = addWrapNodeListMethod;
  scope.wrapNodeList = wrapNodeList;
})(window.ShadowDOMPolyfill);

Simple question: why passing the parameter window.ShadowDOMPolyfill?

Yes, this is an anonymous function that gets executed straight away. Yes all of the variables will stay within the function, avoid pollution. Yes scope will be the same as window.ShadowDOMPolyfill.

This is a pattern I have seen many times. I totally understand why it's good not to pollute the global scope with variables, etc. But, why passing window.ShadowDOMPolyfill as first parameter? As far as I know, the Window object is totally available within functions... so what's the difference between the code above and:

(function() {
  "use strict";
  var scope = window.ShadowDOMPolyfill;
  ...
})();

...?

Answer 1

It's considered good practice to define the parameters your function needs in order to do the work it's assigned to do, in the argument list.

While it's perfectly possible to do it the way you propose, it encourages a lying API, in a sense that you can't look at the function signature and understand what goes into the function.

In this particular instance, the two examples are identical in functionality, however, imagine there being more parameters, and their usages and definitions are scattered across the function body.

(function(oneThing, anotherThing, aThirdThing) {
  ...
})(window.oneThing, window.anotherThing, window.aThirdThing);

is more readable than

(function() {
  ... // with your vars somewhere inside.
})();

In your example, you must enforce a convention with your developers to always put these definitions at the top, to maintain readability. However, the language already helps you enforce that with the argument list.