This would fail if someone is using "old" classes which can be common when transpiling cross-platform code that targets old targets (for example: using tooling that uses es5 at any point)

This would fail if someone is using "old" classes which can be common when transpiling cross-platform code that targets old targets (for example: using tooling that uses es5 at any point)

Maybe you can add a test on test-performance-function.js or just show me an example function(I will add to the former file). I will solve the problem to ensure all tests have been passed.

Sure

function MyClass {
  this.foo = 15;
}
MyClass.prototype.sayFoo {
  console.log(this.foo);
}
const instance = new MyClass(); ?

this.foo = 15;
Hasn't it a return value ?

Sure

function MyClass {
  this.foo = 15;
}
MyClass.prototype.sayFoo {
  console.log(this.foo);
}
const instance = new MyClass(); ?

If a function is like this. Actually, we can't judge which way is to call. Because using new to call and invoke directly is different. So I think we just invoke it directly if the first augment is a function. Using new to call if it is a class. wdyt?

I think that will not work for a large chunk of our ecosystem unfortunately and there are people who still use "old style" constructors or have existing projects that do it. So I think for me personally this not breaking for "old style" classes is important.

Maybe we should change the check from "is it a constructor?" to "is it called as a constructor?". i.e. new.target !== undefined. wdyt?

That sounds like a very reasonable approach to me

Note new.target can be set but the return value can still be overridden by returning something different - so a constructor check is would still need to check the return value

Maybe we should change the check from "is it a constructor?" to "is it called as a constructor?". i.e. new.target !== undefined. wdyt?

Actually. I have considered this problem. It seems like new.target only can be used within a function. I didn't find any way to use it outside of a function.

It seems like new.target only can be used within a function. I didn't find any way to use it outside of a function.

This should be fine. timerified is a function.

It seems like new.target only can be used within a function. I didn't find any way to use it outside of a function.

This should be fine. timerified is a function.

I think we don't need to judge if it is called a constructor. we only judge whether the argument is a function or not. if is a class we use new to call, else we invoked directly.

I don't agree. In my opinion, timerified should be a proxy to the function and behave as much as possible the same as if the function was called directly.

I don't agree. In my opinion, timerified should be a proxy to the function and behave as much as possible the same as if the function was called directly.

There must have been some misunderstanding in there. What I do is just like you said. Are there any conflicts?

The conflict is that, in JavaScript, a function can be a class. What Michaël is saying is that, no matter what we can infer of the argument being a "class" or not, if timerified is invoke using new keyboard (i.e. if new.target !== undefined), we should pass that along.

You marked this conversation as resolved but didn't take my suggestion. Is it because you disagree with it, or because you forgot to push?

@aduh95 wouldn't new.target not be undefined only if timerified() is called with new instead of fn()?

Yes, but that's the point. We want the timerified function to behave the same as the original function in both cases.

Ah, we are returning timerified from timerify. Yea, this makes sense 👍