Currently the compiler aggressively converts functions definitions into simulacrum native code. This leads to lambdas and other higher functions being passed around to get converted as well.
This is usually ok since simulacrum code is perfectly capable of calling these converted higher order functions.
The issue arises when it's not the simulacrum code which is calling this converted functions. For example, filter or any other internal JS function.
Solution
In this PR, we add a simple check before building where arguments of such internal JS functions are checked and an exception is throws if they are explicitly talking converted functions. For example, calling a method from a class.
At the same time, std.lambda is provided as an escape hatch such that the compiler skips conversion.
Showcase Code
const userFromDB = this.userTable.find(
//Rather than directly providing the lambda, we provide it through std
std.lambda(record => record.id === id)
);
Problem
Currently the compiler aggressively converts functions definitions into simulacrum native code. This leads to lambdas and other higher functions being passed around to get converted as well.
This is usually ok since simulacrum code is perfectly capable of calling these converted higher order functions.
The issue arises when it's not the simulacrum code which is calling this converted functions. For example,
filter
or any other internal JS function.Solution
In this PR, we add a simple check before building where arguments of such internal JS functions are checked and an exception is throws if they are explicitly talking converted functions. For example, calling a method from a class.
At the same time,
std.lambda
is provided as an escape hatch such that the compiler skips conversion.Showcase Code