Re: PRs policy

[Jordan Harband]

If we had such a policy, and a PR hit that time window without meeting the
criteria, I'd expect that it would be closed without being merged.

In other words, such a policy would cause open unmerged PRs to be *closed*
- but in no way could, or should, such a policy accelerate *merging*.

The only way that PR can be merged is if tests are added first.

- Jordan

On Sun, Feb 4, 2018 at 1:08 AM, Raul-Sebastian Mihăilă <
raul.miha...@gmail.com> wrote:

> A month ago I opened a github issue (https://github.com/tc39/
> ecma262/issues/1061) in which I asked whether or not TC39 should have a
> policy WRT the time frame in which a PR should be merged. I mentioned that
> there was currently an open PR (https://github.com/tc39/ecma262/pull/666)
> which had consensus, for a confirmed bug that was reported one year and a
> half ago.
>
> It's obviously not always possible to set expectations WRT to time. It's
> possible that at some point a difficult to understand or
> difficult/impossible to fix bug is found. However, in this case, the PR
> already achieved consensus in TC39.
>
> A year ago I held a course about the Javascript object model, invariants
> and internal methods. I mentioned the existing bugs related to proxies. I
> mentioned that there was a PR that would soon be merged and since not many
> people were using proxies at that time, the bugs weren't a serious concern.
> One year later, the PR is still not merged.
>
> This thread isn't about good or bad, although we can think about
> expectations people might have. For instance, in general, when somebody
> works on something, if that thing isn't working properly, it is expected
> that that somebody would fix that issue. Also, as we know, in Javascript
> the older a bug is, the greater the risk that somebody will start depending
> on the bad behavior, which can make it more difficult to fix the bug. It's
> also important to mention that, as we all know, TC39 did a great job
> improving the spec over time.
>
> This thread is about whether or not people can have some expectations WRT
> the time frame in which a bug is fixed. I believe it's easier to set
> expectations WRT PRs that already have consensus and I believe that in this
> case one year and a half is a rather long period. It would be nice if the
> community could have some sort of expectations in the simpler cases.
>
> In that github issue I was told that the PR needed tests (which was
> already obvious) and I was suggested to contribute the tests if I wanted to
> push the feature forward. An important aspect of this story is that the
> initial bug that triggered the whole discussion about these issues was
> found by myself, a volunteer (https://esdiscuss.org/topic/
> object-freezing-proxies-should-freeze-or-throw). The other issues were
> found and the fixes in the PR for the proxies internal methods were done by
> Claude Pache, which as far as I'm aware also did this voluntary (see the PR
> link above). The way I see it, most of the work that was done to push this
> feature forward was already done by volunteers that are not part of TC39. I
> personally am busy with other work and stuff that don't allow me to do the
> testing for this PR.
>
> Therefore:
> 1) Should TC39 have a policy WRT the time frame in which a PR should be
> merged?
> 2) Does a year and a half look like a long period for a PR with consensus
> that hasn't been merged?
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Suggestion : "automatic" context binding

[T.J. Crowder]

Hi,

This already has a Stage 0 proposal here:
https://github.com/tc39/proposal-bind-operator.

You can find all proposals at https://github.com/tc39/proposals in
(currently) three categories: That page itself, which lists proposals for
Stages 1, 2, and 3; and the linked lists of Stage 0 proposals, Inactive
proposals, and Finished proposals.

-- T.J. Crowder


On Sun, Feb 4, 2018 at 4:32 PM, Ludwig GUERIN 
wrote:

> Sometimes, you need to pass a callback as a parameter of a function.
>
> Sometimes, you would like to pass in a method as the said parameter but
> you may encounter the common issue that the this keyword is not bound to
> the correct context anymore ; therefore you need to bind the correct
> context.
>
>
>
> Let's says that you have :
>
>- a function `f` which receives a callback
>-
>
>and an object `obj` which has a method `method` which requires the `
>this` keyword to be bound to `obj` in order to work properly as
>intended.
>
>
>
> You will probably call `f` this way :
>
> `f(obj.method.bind(obj));`
>
>
>
> This is perfectly fine but sometimes can lead to a very large amount of
> extra "effort" for something that should not require that much "effort" and
> tends to take away a lot of space and clarity :`
>
> `f(obj.prop.method.bind(obj.prop));`
>
>
>
> My suggestion to solve this issue would be to use a new notation based
> around what C++ developers call the *scope resolution operator*, aka `::`.
>
> Here are details on how this should work :
>
>-
>
>`{object}` refers to an object (it can be either obj, or obj.method,
>or obj.prop, etc...)
>-
>
>`{method}` refers to one of `{object}`'s methods (if `{object}` is obj
>and we have `obj.method` then `{method}` would be `method`)
>-
>
>The "old-fashioned" way would look like `{object}.{method}.bind({
>object})`
>-
>
>With this suggestion, it would look like `{object}::{method}`
>
>
>
> One way to implement such a functionality would be to establish a function
> autoBindContext which would guarantee the following properties :
>
>-
>
>`{object}::{method}` <=> `autoBindContext({object}.{method}, {object})`
>-
>
>Given any function/method `{fn}` (either `f` or `obj.method`), 
> `autoBindContext({fn},
>null) === {fn}`
>-
>
>`{object}::{method}` <=> `({object})::{method}`
>- const a = {object}::{method};
>const b = {object}::{method};
>a==b; //is true
>a===b; //is true
>
>
>
> Below is one implementation of autoBindContext :
>
> ```javascript
>
> const autoBindContext = (method, context=null) => {
>   if(typeof method !== "function")
> throw new TypeError("Can only bind the context of a function/method");
>
>   if(context === null)
> return method; //Do not bind if the context is null
>
>   if(!(context instanceof Object))
> throw new TypeError("Can only bind a function's/method's context to an 
> object");
>
>   const self = autoBindContext;
>   if(!self.cache.hasBinding(method, context))
> self.cache.addBinding(method, context);
>
>   return self.cache.getBinding(method, context);
> }
> ​
> autoBindContext.cache = {
>   /***\
> binding: {context, method, bound}
>   \***/
> bindings: [],
>   lookForBinding(method, context=null){
> return this.bindings.find(binding => {
>   return binding.context === context
>   && binding.method === method;
> });
>   },
>   hasBinding(method, context=null){
> return this.lookForBinding(method, context) !== undefined;
>   },
>   getBound(method, context=null){
> if(this.hasBinding(method, context))
> return this.lookForBinding(method, context).bound;
>
> return null;
>   },
>   getBinding(method, context=null){
> return this.getBound(method, context);
>   },
>   addBinding(method, context=null){
> if(!this.hasBinding(method, context)){
>   this.bindings.push({
> context,
> method,
> bound: method.bind(context)
>   });
> }
>
> return this;
>   }
> };
>
> ```
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Suggestion : "automatic" context binding

[Ludwig GUERIN]

Sometimes, you need to pass a callback as a parameter of a function.

Sometimes, you would like to pass in a method as the said parameter but you may encounter the common issue that the this keyword is not bound to the correct context anymore ; therefore you need to bind the correct context.

 

Let's says that you have :


	a function `f` which receives a callback
	
	and an object `obj` which has a method `method` which requires the `this` keyword to be bound to `obj` in order to work properly as intended.

	 
	


You will probably call `f` this way :

`f(obj.method.bind(obj));`

 

This is perfectly fine but sometimes can lead to a very large amount of extra "effort" for something that should not require that much "effort" and tends to take away a lot of space and clarity :`

`f(obj.prop.method.bind(obj.prop));`

 

My suggestion to solve this issue would be to use a new notation based around what C++ developers call the scope resolution operator, aka `::`.

Here are details on how this should work :


	
	`{object}` refers to an object (it can be either obj, or obj.method, or obj.prop, etc...)
	
	
	`{method}` refers to one of `{object}`'s methods (if `{object}` is obj and we have `obj.method` then `{method}` would be `method`)
	
	
	The "old-fashioned" way would look like `{object}.{method}.bind({object})`
	
	
	With this suggestion, it would look like `{object}::{method}`
	


 

One way to implement such a functionality would be to establish a function autoBindContext which would guarantee the following properties :


	
	`{object}::{method}` <=> `autoBindContext({object}.{method}, {object})`
	
	
	Given any function/method `{fn}` (either `f` or `obj.method`), `autoBindContext({fn}, null) === {fn}`
	
	
	`{object}::{method}` <=> `({object})::{method}`
	
	
	const a = {object}::{method}; 
	const b = {object}::{method}; 

	a==b; //is true 
	a===b; //is true 
	


 

Below is one implementation of autoBindContext :

```_javascript_

const autoBindContext = (method, context=null) => {
  if(typeof method !== "function")
throw new TypeError("Can only bind the context of a function/method");
  
  if(context === null)
return method; //Do not bind if the context is null
    
  if(!(context instanceof Object))
throw new TypeError("Can only bind a function's/method's context to an object");
    
  const self = autoBindContext;
  if(!self.cache.hasBinding(method, context))
self.cache.addBinding(method, context);
    
  return self.cache.getBinding(method, context);
}
​
autoBindContext.cache = {
  /***\
binding: {context, method, bound}
  \***/
bindings: [],
  lookForBinding(method, context=null){
return this.bindings.find(binding => {
      return binding.context === context
      && binding.method === method;
    });
  },
  hasBinding(method, context=null){
return this.lookForBinding(method, context) !== undefined;
  },
  getBound(method, context=null){
if(this.hasBinding(method, context))
    return this.lookForBinding(method, context).bound;
    
    return null;
  },
  getBinding(method, context=null){
return this.getBound(method, context);
  },
  addBinding(method, context=null){
if(!this.hasBinding(method, context)){
      this.bindings.push({
        context,
        method,
        bound: method.bind(context)
      });
    }
    
    return this;
  }
};

```

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

PRs policy

[Raul-Sebastian Mihăilă]

A month ago I opened a github issue (
https://github.com/tc39/ecma262/issues/1061) in which I asked whether or
not TC39 should have a policy WRT the time frame in which a PR should be
merged. I mentioned that there was currently an open PR (
https://github.com/tc39/ecma262/pull/666) which had consensus, for a
confirmed bug that was reported one year and a half ago.

It's obviously not always possible to set expectations WRT to time. It's
possible that at some point a difficult to understand or
difficult/impossible to fix bug is found. However, in this case, the PR
already achieved consensus in TC39.

A year ago I held a course about the Javascript object model, invariants
and internal methods. I mentioned the existing bugs related to proxies. I
mentioned that there was a PR that would soon be merged and since not many
people were using proxies at that time, the bugs weren't a serious concern.
One year later, the PR is still not merged.

This thread isn't about good or bad, although we can think about
expectations people might have. For instance, in general, when somebody
works on something, if that thing isn't working properly, it is expected
that that somebody would fix that issue. Also, as we know, in Javascript
the older a bug is, the greater the risk that somebody will start depending
on the bad behavior, which can make it more difficult to fix the bug. It's
also important to mention that, as we all know, TC39 did a great job
improving the spec over time.

This thread is about whether or not people can have some expectations WRT
the time frame in which a bug is fixed. I believe it's easier to set
expectations WRT PRs that already have consensus and I believe that in this
case one year and a half is a rather long period. It would be nice if the
community could have some sort of expectations in the simpler cases.

In that github issue I was told that the PR needed tests (which was already
obvious) and I was suggested to contribute the tests if I wanted to push
the feature forward. An important aspect of this story is that the initial
bug that triggered the whole discussion about these issues was found by
myself, a volunteer (
https://esdiscuss.org/topic/object-freezing-proxies-should-freeze-or-throw).
The other issues were found and the fixes in the PR for the proxies
internal methods were done by Claude Pache, which as far as I'm aware also
did this voluntary (see the PR link above). The way I see it, most of the
work that was done to push this feature forward was already done by
volunteers that are not part of TC39. I personally am busy with other work
and stuff that don't allow me to do the testing for this PR.

Therefore:
1) Should TC39 have a policy WRT the time frame in which a PR should be
merged?
2) Does a year and a half look like a long period for a PR with consensus
that hasn't been merged?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss