add bind option

[jamestalmage]

By default, it binds functions to the original object.

If opts.bind is false. It does not bind to the original object, and copies over all non-function properties.

Closes #26.

[jamestalmage]

See the first commit.

There I added accessor methods that delegate to the bound object. That seems like overkill, still it might be nice:

var x = {
  option: 'foo',
  method: function(cb) {
    setImmediate(() => cb(null, this.option));
  }
}

var y = pify(x);

// With delegate accessors you could do:
y.option = 'bar';
y.method().then(...);

// Without delegate accessors you need to remember to set on x:
x.option = 'bar';
y.method().then(...);

I removed that in the second commit (code is a lot smaller / cleaner without the feature)

[schnittstabil]

@jamestalmage Is there a reason not to use opts.bind?

[jamestalmage]

Yeah. It caused the optimization test to fail (not sure why, but the optimization killers blog post does mention something about fn.bind().

Also, we are already calling fn.apply(someObj, args) anyways. Adding a layer of indirection where this doesn't end up being someObj seems confusing.

[sindresorhus]

@schnittstabil @SamVerschueren What do you think about handling getter/setters too 32e5fe7? It kinda makes sense to me.

[sindresorhus]

// @kevinoid @LinusU @rightaway @dsblv @julien-f

[LinusU]

I don't know if it's preferred, but setImmediate will pass on any extra arguments, so this could be written like this:

setImmediate(cb, null, this.x);

[jamestalmage]

I can update the PR, but do we want the property accessors when binding, or not?

[sindresorhus]

@jamestalmage I'm not sure. Are there any potential downsides to it? What does bluebird.promisify do? I'm just afraid of it having some pitfalls and requiring yet another major release at some point later.

[jamestalmage]

I don't think bluebird binds anything but methods

[schnittstabil]

In my personal vision, pify(obj) will return an ECMAScript6 Proxy object when available, forwarding almost all operations to obj, and promisifying only some functions.

Based on this idea:

1. pify(obj).foo = 42; would modify obj
2. binding to an other object than obj would be out of scope of pify

Therefore I don't see any downsides providing 1.

[jamestalmage]

@schnittstabil - That's basically what the first commit does (and the second commit undoes). It's not a complete proxy object (the property has to exist at the time of promisification).

[schnittstabil]

@jamestalmage I wanted to show, that I don't believe, that your suggestion have to be reverted in the future.
Despite this, Object.keys only returns own properties, thus 32e5fe7 doesn't work with inheritance!?

[jamestalmage]

Despite this, Object.keys only returns own properties, thus 32e5fe7 doesn't work with inheritance!?

Yeah. I had that thought recently and forgot to mention it. If everybody is 👍 on the feature, I will revert the second commit and just do all enumerable properties (or do we need non enumerable too?)

[sindresorhus]

If everybody is 👍 on the feature, I will revert the second commit and just do all enumerable properties

👍

(or do we need non enumerable too?)

Nah. They're non-enumerable for a reason.

[sindresorhus]

In my personal vision, pify(obj) will return an ECMAScript6 Proxy object when available, forwarding almost all operations to obj, and promisifying only some functions.

@schnittstabil I really like this idea. Mind opening an issue so we can consider doing that in the future?

[jamestalmage]

Hmmm:

class Foo {
  bar () {}
}

new Foo().propertyIsEnumerable('bar');
// => false

[sindresorhus]

@jamestalmage Agh. I forgot that ES2015 class members are non-enumerable. I guess we have to get those too then.

[schnittstabil]

Because of #36 (comment), I believe the best way to deal with this is a dedicated bind library, bind-all seems suitable:

// instead of 
const y = pify(x, {bind: true});

// we can use a bind library
const y = pify(bindAll(x));

I believe the semantics would be more clear. Furthermore, the loss of performance seems to be negligible, because we have to bind all(relevant!?) functions, not only the functions we want to promisify.