Lexically Scoped Object Extensions (was About private names)

David Herman dherman at mozilla.com
Tue Mar 22 00:21:34 PDT 2011


I wish you would make your proposal more precise; right now we have to infer it from your single example. In my conversations with several others on the committee, I'm already seeing lots of confusion about the semantics of what you are describing here. Can you write this up as a strawman in more detail?

Specifically:

- you haven't made clear whether the semantics does a dynamic property add and property delete at the beginning and end of the scope;

- you haven't made clear what the property key that 'filter' refers to in the example actually is; and

- you haven't made clear whether there's any way that external code transitively called during the lifetime of the block could access the 'filter' property.

I also have to call a foul when you claim that this can do something that private names can't but then declare it out of bounds for anyone else to discuss the validity of that claim.

Sorry if this is a little grumpy. It's just that we're all very busy and it would help prevent runaway threads if we cut down on noise due to avoidable confusion.

Dave

On Mar 21, 2011, at 1:13 PM, Erik Arvidsson wrote:

> The thread about using private names is getting a bit unwieldy but I'd
> like to focus on the  use case that I have been thinking of as
> "Lexically scoped monkey patching" or "Lexically scoped object
> extensions" instead of focusing on how to use "private names" to fit
> this scenario.
> 
> Extending built ins and modifying existing classes to work around bugs
> or to provide a better API is (or was) a common pattern. Today a lot
> of JS library shun this approach due to the risk of conflicts.
> 
> Let us assume that you could extend an object in your current lexical
> scope and that such extensions could be imported from a module into
> your current scope.
> 
> Given:
> 
> {
>  function largerThanN(obj, n) {
>    return obj.filter(function(item) {
>      return item > n;
>    }
>  }
> 
>  var a = [0, 1, 2, 3, 4];
>  print(largerThanN(a, 2));
> }
> 
> Now we would like to make largerThanN to work with Object objects. The
> naïve thing to do is to just to add a filter method to
> Object.prototype. However, this might cause conflicts with other code
> that uses objects. The idea here is that we can do this safely in our
> scope (ignore syntax except that it is important that it can be done
> statically).
> 
> {
>  extend Object.prototype with {
>    filter: function(fun) {
>      var retval = {};
>      for (var key in this) {
>        if (fun(this[key])
>          retval[key] = this[key];
>      }
>      return retval;
>    }
>  };
> 
>  function largerThanN(obj, n) {
>    return obj.filter(function(item) {
>      return item > n;
>    }
>  }
> 
>  var a = [0, 1, 2, 3, 4];
>  print(largerThanN(a, 2));
>  var o = {a: 0, b: 1, c: 2, d: 3, e: 4};
>  print(largerThanN(0, 2));
> }
> 
> The above use case cannot be solved using private names because
> private names conflict with public names.
> 
> Can we agree that this is a use case that we care about and focus on
> this instead of whether private names can or cannot do this?
> 
> -- 
> erik
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list