LGTM FWIW.

I suppose one question that needs answering is whether domain.run() is performance-sensitive enough that adding a slice+apply introduces noticeable overhead. I'm guessing the answer is 'no' but I don't use domains enough to really know for sure. Opinions?

@micnic Can you make the commit log conform to the template as described in CONTRIBUTING.md? Thanks.

@bnoordhuis I agree. Also it's possible just to call enter() and exit() manually

@bnoordhuis, I'll add a switch for different cases as @vkurchatkin proposes.

related to the commit log, should I make a new pull request or just another commit with a more verbose description? (it's my first PR)

@micnic That's a good idea but can you then also add a small benchmark in benchmarks/ that shows that the switch statement actually speeds things up? Thanks.

As to the commit log, you can just git commit --amend it and and force-push it to your feature branch (or git rebase -i it when you add that benchmark.)

@bnoordhuis, I added the benchmark and made some changes to the arguments slicing logic to:

if (arguments.length >= 2) {
  args = Array.prototype.slice.call(arguments, 1);
  ret = fn.apply(this, args);
} else {
  ret = fn.call(this);
}

it's similar to what is used in setInterval() or setTimeout, from the benchmark I did not observe any performance impact.

Now, what I discovered is that we also should bind the arguments to the domain if they may emit any errors, take in count this use case:

var domain = require('domain');
var events = require('events');

var dom = domain.create();
var emitter = new events.EventEmitter();

dom.on('error', function (error) {
  console.log(error.message + ' is caught');
});

dom.run(function (ee) {
  ee.emit('someEvent');
}, emitter);

// This error is not caught by the domain
emitter.emit('error', new Error('Oh No!'));

What do you think about explicitly binding the arguments to the domain?

What do you think about explicitly binding the arguments to the domain?

sounds counterintuitive and probably will cause lots of confusion

Hello!

I am pleased to see your valuable contribution to this project. Would you
please mind answering a couple of questions to help me classify this submission
and/or gather required information for the core team members?

Questions:

1. Which part of core do you think it might be related to?
   One of: debugger, http, assert, buffer, child_process, cluster, crypto, dgram, dns, domain, events, fs, http, https, module, net, os, path, querystring, readline, repl, smalloc, stream, timers, tls, url, util, vm, zlib, c++, docs, other (label)
2. Which versions of io.js do you think are affected by this?
   One of: v0.10, v0.12, v1.0.0 (label)
3. PR-only Does make test pass after applying this Pull Request.
   Expected: yes
4. PR-only Is the commit message properly formatted? (See
   CONTRIBUTING.md for more information)
   Expected: yes

Please provide the answers in an ordered list like this:

1. Answer for the first question
2. Answer for the second question
3. ...

Note that I am just a bot with a limited human-reply parsing abilities,
so please be very careful with numbers and don't skip the questions!

In case of success I will say: ...summoning the core team devs!.

In case of validation problem I will say: Sorry, but something is not right here:.

Truly yours,
Caine.

Responsibilities

1. indutny: crypto, tls, https, child_process, c++
2. trevnorris: buffer, http, https, smalloc
3. bnoordhuis: http, cluster, child_process, dgram

1. domain
2. v0.12
3. yes
4. yes

...summoning the core team devs!

I think this conflicts with #66. I'll bring it up in the TC meeting today; if we are going to deprecate domains, it doesn't make sense to extend the API.

This PR is ready for merge, I made the demanded changes

cc @bnoordhuis @trevnorris

@micnic @chrisdickinson will take it from here, he graciously volunteered to shepherd this PR.